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Preface 


This document is one of three prepared under NASA (Langley Research Center) 
grant number NAG1- 1-1327. Collectively these documents form the technical report covering 
the research activites for the period of time from July 1 , 1994 to December 3 1 , 1994. The three 
documents consist of the following: 

1 . Integrating O&S Models During Conceptual Design - Part I 

Summarizes the overall study , objectives , and results. Discusses in detail enhancements 
made to the models developed under this grant , 

2. Integrating O&S Models During Conceptual Design - Part II 
Reliability and Maintainability Model (RAM), User and Maintenance Manual 

Provides detailed documentation on the RAM model , its execution , and procedures for 
conducting a study using the model . A complete source listing is provided, 

3. Integrating O&S Models During Conceptual Design - Part in 
Simulation of Maintenance and Logistics Support of Proposed Space Systems 
Using SLAM II. 

Documents the SLAM maintenance simulation model which provides for more accurate 
determination of maintenance manpower requirements , A complete example of its use is provided . 
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manpower and vehicle requirements for the proposed vehicle to meet its desired mission 
rate 

This model has been developed under a grant from NASA and is described in 
detail herein. The grant is a continuation of an earlier grant given to Dr. Charles Ebeling 
of the School of Engineering of the University of Dayton, Dayton, Ohio to develop and 
implement a methodology for predicting the reliability and maintainability of proposed 
space vehicles. The predicted reliability and maintainability values are inputs to this 
model. The outputs of this model are used as inputs to a model used to estimate the life 
cycle costs of proposed space vehicles that Dr. Ebeling has also developed under the 
same grant with NASA. (University of Dayton Research Institute proposal R-9657) 

A. Background 

Dr. Charles Ebeling of the University of Dayton has developed a methodology for 
estimating measures of reliability and maintainability such as the mean time between 
maintenance actions (MTBM), maintenance hours per maintenance action (MH/MA) 
which is used in calculating the mean time to repair (MTTR), average crew size per 
maintenance task (CREW), and spares requirements for proposed space vehicles 
(Ebeling). 

Equations for estimating these measures as functions of vehicle design and 
performance specifications were obtained through regression analysis on a large data 
base of actual aircraft and space shuttle subsystem reliability and maintainability data. 

For example, the Air Force and Navy keep data on the times between maintenance 
actions of their aircraft health monitoring avionics subsystems. Design and performance 
specifications of these aircraft, such as number of engines, BTU cooling capacity, vehicle 
length plus wing span, and subsystem weights, are also known. Multiple regression 
analysis of the maintenance data against the design and performance specifications has 
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CHAPTER I 


INTRODUCTION 


Space vehicles, such as the Space Shuttle, require intensive ground support prior 
to, during, and after each mission. Maintenance is a significant part of that ground 
support. All space vehicles require scheduled maintenance to ensure operability and 
performance. In addition, components of any vehicle are not one-hundred percent 
reliable so they exhibit random failures. Once detected, a failure initiates unscheduled 
maintenance on the vehicle Maintenance decreases the number of missions which can 
be completed by keeping vehicles out of service so that the time between the completion 
of one mission and the start of the next is increased. Maintenance also requires resources 
such as people, facilities, tooling, and spare parts. Assessing the mission capability and 
resource requirements of any new space vehicle, in addition to performance 
specifications, is necessary to predict the life cycle cost and success of the vehicle. 

Maintenance and logistics support has been modeled by computer simulation to 
estimate mission capability and resource requirements for evaluation of proposed space 
vehicles. The simulation was written with Simulation Language for Alternative 
Modeling II (SLAM II) for execution on a personal computer. Forone or a fleet of space 
vehicles, the model simulates the preflight maintenance checks, the mission and return to 
earth, and the post flight maintenance in preparation to be sent back into space. The 
model enables prediction of the number of missions possible and vehicle turn-time (the 
time between completion of one mission and the start of the next) given estimated values 
for component reliability and maintainability. The model also facilitates study of the 
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resulted m the following equation for MTBM of the health monitoring avionics 
subsystem: 

MTBM =323.9 1 3-1 6.0757^^ wt +16.974 (len+ wing )+l 735(t/ve_w/ ) 

+23.8( nhrjiff _subsys}-2305{ UVe - Wt / nhr ave _ subsys ) 

The MTBM of all the subsystems are calculated similarly and are then used to calculate 
the vehicle's MTBM The other reliability and maintainability measures are estimated in 
a similar way. 

Information is, of course, limited for conceptual systems. Therefore, the design 
and performance specifications as well as subsystem weights, if not known, can be 
estimated by equations which are functions of variables known early in the design stage: 
vehicle weight, vehicle's length plus it's wing span, crew size, number of passengers, and 
number of main engines. These equations were obtained from multiple regression 
analysis on a data base of actual aircraft and space shuttle data by the same method 
described in the above paragraph. 

Dr Ebeling has written a computer program which allows the user to input the 
overall vehicle parameters, to input the subsystem weights if known, or input the 
subsystem weights and design and performance specifications if known. The program 
then calculates the various reliability and maintainability measures and displays them in 
tabular form. These calculated measures such as manpower (CREW) and spares 
requirements, in addition to operations, logistics, and systems support, facility and 
hardware, and development requirements, can be used to compute the proposed vehicle's 
total life cycle costs. 

Dr. Ebeling has also developed a model to estimate operating and support costs 
throughout the life of a system, i.e., operating, logistic support, and maintenance costs, 
facility and tooling costs, and manpower and spares costs. The manpower and spare 
requirements as calculated by the Reliability and Maintainability Model are two of the 
many inputs to a computer program which implements the Life Cycle Costing Model. 
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The program calculates the various costs and then outputs them by function (operations, 
development, etc ), by subsystem (health monitoring avionics, propulsion, etc ), and by 
configuration (orbiter, boosters, etc.) 

B. Problem Statement 

The values for manpower and spare parts requirements from the Reliability and 
Maintainability Model do not account for the stochastic nature of vehicle failure and 
repair times. Subsystem manpower requirements are calculated from equations obtained 
by regression analysis of known average crew sizes against the proposed vehicle's design 
specifications (body length, vehicle dry weight, etc.) as described in Section A. If there 
was not a significant tit of the data, the average crew size was used. The values for 
manpower, therefore, do not take into account that some repairs will take longer than 
others and that failures which require the same maintenance crew will occur close in 
time because the failure and repair times are not deterministic but probabilistic. During 
actual operation, mission capability could be reduced and costs increased as a vehicle is 
out of service longer (long turnaround times) and other vehicles which require the same 
service must wait (thereby increasing turnaround times even more). A simulation of the 
operation of a fleet of vehicles based on the reliability (MTBM) and maintainability 
(MTTR) of the vehicle's subsystems for a given mission duration can more accurately 
predict the manpower and vehicle requirements needed to meet a desired mission rate. 
These values can be input into the Life Cycle Costing Model instead of the Reliability 
and Maintainability Model’s values for more accurate cost estimation. 

C. Objectives 

The primary objective of this effort has been to develop a methodology to 
estimate the number of crews, the number of vehicles, and the maintenance turn around 
time required to meet established mission plans for proposed space vehicles. The first 
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goal has been to develop a computer simulation which uses the Reliability and 
Maintainability Model's deterministic values of MTBM and MTTR as mean values for 
probability distributions in a model of the pre-flight loading and maintenance, the 
mission and return to earth, and post-flight maintenance for one or a fleet of proposed 
space vehicles. The second goal has been to write a detailed description of the model 
and extensive guidelines for using the model to obtain valid estimates for the number of 
crews and vehicles needed as the model will be used by NASA personnel in conjunction 
with the Reliability and Maintainability Model and Life Cycle Costing Model during 
conceptual design of space vehicles. 

D. Overview 

The simulation model and its application are presented in detail in the remaining 
chapters of this thesis A literature search resulted in a few very relevant publications to 
this subject. Summaries of these publications are in Chapter 2. A description of the 
model and the assumptions made during the development of the model are presented in 
Chapter 3. Guidelines for how to use the model and an example of running the model 
with actual data are given in Chapter 4. Concluding remarks are presented in the final 
chapter. 
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CHAPTER II 


REVIEW OF CURRENT LITERATURE 


Some literature pertinent to this simulation study was provided by Dr. Charles 
Ebeling. In addition, literature was obtained through the library at Wright State 
University and the Technical Information Center at General Electric Aircraft Engines. A 
discussion of the most relevant literature follows. 

W.D. Morris, T.A. Talay, and D.G. Eide used SLAM to model the resources and 
activities necessary to support the operation of a proposed reusable space vehicle 
designed to deliver cargo to the space station and then return to earth for maintenance, 
loading, and another launch into space. The model permitted study of the number of 
vehicles, size of cargo bay, number of facilities, and inclination angle (to determine best 
launch window) needed to meet the required cargo delivery rate as efficiently as possible. 
Failure rates for the vehicle were not modeled and various maintenance times were 
postulated to determine the effect of maintenance on number of vehicles, size of cargo 
bay, etc. Although this model does not parallel the simulation in this study, the 
discussion of the advantages of using simulation to study the operations of space vehicles 
to ensure mission readiness and to estimate the entire life cycle cost of the vehicle 
instead of focusing entirely on performance is relevant and accurate. (Morris, W.D., 
Talay, T.A., and Eide) 

In his Master's Thesis "A Simulation Model for Determining the Effect of 
Reliability and Maintainability on Maintenance Manpower Requirements and Mission 
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Capabilities," Captain Myron Lewellen describes his use of SLAM II to model the 
operations of a squadron of twenty-four fighter aircraft for one year. Captain Lewellen 
modeled the pre-flight inspection, the mission completion given daylight and acceptable 
weather, the post-flight inspection, and the reuse of an aircraft for another mission or the 
removal of an aircraft from service for unscheduled or scheduled maintenance. Each 
aircraft was modeled as having twenty-one subsystems each with its own reliability 
(mean time to failure) and maintainability (mean time to repair) parameters (values 
determined from historical data) and requiring four scheduled maintenance actions. 
When a subsystem failed or the aircraft was due for scheduled maintenance, the aircraft 
was removed from service for the length of time of the required maintenance action at a 
subsystem dedicated facility Captain Lewellen's efforts focused on determining the 
effect of improving the reliability and maintainability of the subsystems on the 
availability of fighters to complete missions as measured in number of sorties flown and 
the required manpower as measured by number of man-hours to meet a desired (target) 
sortie rate. His strategy of modeling an aircraft as a collection of subsystems each with 
its own reliability and maintenance requirements was used in this study. (Lewellen) 
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CHAPTER III 


SIMULATION MODEL 

A simulation model has been written with Simulation Language for Alternative 
Modeling (SLAM) on a personal computer. The model uses the mean time between 
maintenance (MTBM), mean time to repair (MTTR), and other values from the 
Reliability and Maintainability Model to estimate the manpower requirements, the effect 
of spares support, and the mean operation and processing turnaround time for proposed 
space vehicles. An overview of the vehicle operation and support processes, the 
assumptions made during development of the model, and a detailed description of the 
model follows. 

A. Vehicle Operation and Support Processes 

The model simulates all of the operation and support processes required for one 
or a fleet of proposed space vehicles to meet the overall mission/project goals. A diagram 
of a vehicle’s processing and mission is presented in figure 1. An available vehicle is 
matched with a scheduled mission. The vehicle then undergoes integration (the boosters 
and payload are installed), pad processing (launch preparation and final inspection), and 
launch. For a small percentage of missions, a critical failure will occur resulting in a 
mission abort with a subsequent delay to replace the affected vehicle. Otherwise, the 
vehicle successfully completes the mission. Upon return to earth, the vehicle undergoes 
safing (inspection for dangerous conditions). Unscheduled and scheduled maintenance 
are then performed on each of the vehicle’s systems as needed. 



The unscheduled and scheduled maintenance processes are diagrammed in figure 
2 If a system had one or more failures during the mission, unscheduled maintenance 
followed by scheduled maintenance is performed on that system. The number of failures 
is determined by a Poisson distribution with a mean equal to the average number of 
failures per mission for that system (mission operating hours divided by MTBM from the 
Reliability and Maintainability Model). 

An unscheduled maintenance action is initiated for each failure. Some of these 
maintenance actions results in the removal of a component. If a spare is not available, 
the removed component is repaired immediately and is installed back onto the vehicle. If 
a spare is available, the component is replaced with a spare. Repair of the removed 
component is done after scheduled maintenance as ‘off-vehicle unscheduled 
maintenance’. Once all of the unscheduled maintenance actions are completed, 
scheduled maintenance begins. If no failures occurred during the mission, scheduled 
maintenance is performed directly. 

Scheduled maintenance is done both on and off-vehicle. All of the on-vehicle 
maintenance is completed before the off-vehicle begins. As soon as the on-vehicle 
scheduled maintenance is complete, maintenance on another system can begin if the 
appropriate repair crew is available. The current repair crew will then finish the off- 
vehicle scheduled and unscheduled maintenance (repair of removed components) for the 
current system. The vehicle is ready for another mission when the on-vehicle 
maintenance for all of the systems has been completed. 
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FIGURE 1: VEHICLE IKOCESING AND MISSION OVERVIEW 














FIGURE 2: UNSCHEDULED AND SCHEDULED MAINTENANCE PROCESSES 
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B Assumptions 

The Reliability and Maintainability Model calculates reliability and 
maintainability parameters such as MTBM and MTTR values for up to thirty-three 
subsystems; the number of subsystems defining the proposed vehicle is user input. One 
simplifying assumption used in developing the simulation model was that the thirty-three 
subsystems could be aggregated into nine major systems for simulating maintenance. 

This aggregation was based upon assumed maintenance specialties. The necessary 
parameter values for a system were obtained from the values for the subsystems 
comprising that particular system. Figure 3 shows how the nine systems are defined. 

The numbers in parenthesis refer to the work breakdown structure (WBS) used in the 
Reliability and Maintainability Model for identifying the subsystems. 

Assumptions were also made about the sequence in which the nine subsystems 
would be repaired. For example, it was assumed that the avionics system could not be 
repaired until after the power system was repaired. These two systems must be repaired 
in series. The structure and tanks systems must also be repaired before all other systems 
but the power system. Therefore, these three systems can be repaired in parallel. Figure 
4 shows the sequence in which all nine systems are assumed to be repaired. The numbers 
preceding the system names correspond to attribute, global variable, and file indices used 
in the simulation model for those subsystems. For example, attribute 1 of each entity in 
the model representing a vehicle is the number of failures for the power system. Other 
sequences are possible. The simulation can be modified so that the sequence modeled 
represents the analyst’s best estimate of how maintenance will actually be performed. 
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1. POWER SYSTEMS (9.10.9.20, 9.30, &10.00): APU, BATTERY, FUEL CELL, & ELECTRICAL 

2. STRUCTURE (1.00,200,&3.00): WING , TAIL , AND BODY GROUPS 

3. TANKS (3.10&3.20): LOX TANKS AND LH2 TANKS 

4. AVIONICS (13.10, 13.20, 13.30, 13.40, 13.50&13.60): GM & C, HEALTH MONITOR, COMM & 

TRACK, DISPLAYS & CONTR, INSTRUMENTS, AND DATA PROC 

5. THERMAL PROTECTION (4.10.4.20&4.30): IEP-TILES.TCS, AND PVD 

6. AUXILIARY SYSTEMS (16.30, 16.40, 16.50&16.60): REC & AUX- SEPARATION, CROSS 

FEED, DOCKING SUPPORT, AND MANIPULATOR 

7. LIFE SUPPORT (14.10,14.40,15.00, 16.10&16.20): ENVIRONMENTAL CONTROL ECS- LIFE 

SUPPORT, PERSONNEL PROVISION, REC & AUX-PARACHUTES, AND REC & AUX- 
ESCAPE SYSTEM 

«. MECHANICAL SYSTEMS (5.00.11.00&12.00): LANDING GEAR, HYDRAULICS/ 
PNEUMATICS, AND AERO SURFACE ACTUATORS 

9. PROPULSION (6.00 , 7 .00 &8. 00): MAIN, RCS, & OMS 



FIGURE 3: DEFINITION OF MODEL'S NINE SYSTEMS 
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The assumption is made that each system has its own dedicated repair crew or 
crews, i.e.. there is at least one specialized repair crew for each system. The number of 
crews assigned to a particular subsystem can be modified within the model. The number 
of personnel assigned to a crew is the crew size’ from the Reliability and Maintainability 
Model and is not explicitly considered within the simulation model. 

Lastly, weather was not considered in the model. Weather certainly may delay 
the launch of a vehicle. These delays will affect the number of missions possible in a 
year. Also, a delayed landing due to a delayed launch or due to stormy weather will 
shorten the time between the landing of a vehicle and the scheduled start of its next 
mission. If maintenance cannot be completed in this time, its next mission will be 
delayed. Typically, the maintenance crews have idle time (crews finish one vehicle and 
then must wait for the next to land) that could be used to finish maintenance on a delayed 
vehicle so it is available on time for its next mission. Alternatively, overtime could be 
used to shorten the duration of maintenance. Overtime is also not explicitly considered 
in the model. 

C. Model Description 

The SLAM code is presented in Appendix A. It was written with SLAM 
SYSTEM on a personal computer. The program was designed so that a person with 
some knowledge of SLAM and SLAM SYSTEM could modify the code to model 
specific vehicles and applications. A full description of the code follows. 
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The program was written in three major sections: Primary Operation and 
Processing, System Maintenance, and User Input. The Primary Operation and Processing 
section simulates the vehicle processing and mission activities shown in figure 1. The 
System Maintenance section simulates the on-vehicle unscheduled, scheduled, and off- 
vehicle unscheduled maintenance processes shown in figure 2. The code for both of 
these sections is in the network file’. Nearly all of the necessary input values such as 
system MTBM and MTTR are entered into the ‘control file’ or User Input section of 
code. Each section is described separately below. 

( 1 ) Primary Operation and Processing 

The model was designed to be simple, to use the least amount of code possible, 
and to be flexible. The most complicated aspect of the Primary Operation and 
Processing section to design and code was work shifts The model had to be flexible so 
that simulations could be run with one, two, or three 8-hour shifts per day. For both one 
or two shifts per day, it would be possible that an activity would be started but not 
completed at the end of the last working shift on a particular day. That activity would 
then be completed at the start of the first working shift on the next day. The most 
common way to model work shifts is to remove the resources at the end of the last 
working shift so none are available during the off-shifts. The resources are then added 
back in at the start of the next working shift. However, code must also be added so that 
any activity which was not finished at the end of the last working shift is worked on at 
the start of the next working shift. Since each of the nine systems acquires and frees 
resources three times (for on-vehicle unscheduled, scheduled, and off- vehicle 
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unscheduled maintenance), a significant amount of code would be needed to model shift 
changes in this wav 

Alternatively, this model simulates all activities occurring continuously regardless 
ot how many shifts are actually worked per day and then adjusts the primary outputs, 
maintenance duration and vehicle turnaround time, for one, two, or three 8-hour shifts. 
For example, if a system only has one resource (crew) available and three failures have 
occurred, the model simulates these three maintenance actions as occurring in series and 
continuously until complete. Assume that the three maintenance actions took 12 hours 
for this system. The maintenance duration in actual 24-hour days based on one 8-hour 
shift per day is calculated by dividing the continuous repair time of 12 hours by the 
number of hours worked in a day: 12/8=1 5 days. Therefore, if only one shift were 
worked per day, it would take one and a half days to complete the maintenance on this 
system. Similarly, if two or three shifts were worked per day, the maintenance duration 
would be 12/16=75 or 12/24= 5 days respectively. Vehicle turnaround time in days is 
calculated the same way. 

The Primary Operation and Processing section starts with two calculations needed 
because of the continuous working hours modeling approach described above (refer to 
figure 5). First, the time between missions must be calculated. In actual 24-hour days, if 
28 missions are to be completed each year at regular intervals, one mission must occur 
every 1 .86 weeks or 3 1 3 hours. However, since the model simulates all activities 
occurring continuously, the time between missions must be in continuous working hours 
which is based on the number of hours worked in a 24-hour day: 
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I1GURE 5: PRIMARY OPERATION AND PROCESSING SECTION 





















52wks ! \r * NbrDavs Worked i wk * NbrHrsWorked / dav 

l me BctweenMissiom = : : — 

NbrMissions / vr 

If 24 hours (3 shifts) are worked each day for 7 days a week, the time between missions 
is 3 1 3 hours. However, if 28 missions are required each year, 5 days are worked each 
week, and only 8 hours are worked each day, then the time between missions is 
52*XX(81)*XX(80)/XX(92)=74.3 hours where XX(81)=5, XX(80)=8, and XX(92)=28. 

A create node' at the beginning of the code creates an entity so that this value is 
calculated and assigned to global variable XX(84). Its use is described below. (The 
variables used in this and other calculations are entered as global variables in the control 
file as described in the User Input Section.) 

The other required calculation is the duration of the simulation in working hours. 
It is calculated by: 

SimDuration = NbrYrs * 52 wks / yr* NbrDaysWorked / wk* NbrHrsWorked / day 
This value is calculated and assigned to global variable XX(85) just after the time 
between missions node. Then an ‘activity’ with duration equal to the simulation duration 
routes the entity to a terminate node’ with termination count set at one so that the arrival 
of the entity ends the simulation. 

A create node with time between creations equal to the time between missions as 
calculated above creates one entity for each mission. The entity then waits in a ‘queue’ 
node until a vehicle is available. A create node creates one entity for each vehicle 
available at the beginning of the simulation. These ‘vehicle entities’ wait in a queue 
node until a mission is available. A ‘match node’ matches a mission to a vehicle as soon 
as each is available from their respective queues. 
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The vehicle entity then goes through a series of ‘assign’ nodes. The first node 
sets one of the entity's attributes equal to the current simulation time. This time will be 
subtracted from the time at which the vehicle's maintenance is completed to calculate the 
vehicle turnaround time. The remaining nodes assign the number of failures occurring 
for a system to a specific attribute. For example, the number of failures for the power 
system is assigned to the 1 st attribute. Recall that the number of failures for a system is 
determined by a Poisson random variable with mean equal to the system’s average 
number of failures per mission (calculated by the Reliability and Maintainability Model 
and input by the user). 

The vehicle entity then passes through a series of activities representing 
integration processing, pad processing, the mission, and safing. The durations of these 
activities are entered in hours into the control file as global variables (described in User 
Input Section) The duration of the mission must be adjusted to account for the number 
of hours worked per day In actuality, missions must occur continuously. For example, if 
a mission duration is 72 hours, the elapsed time from mission start to finish is 72 hours or 
three 24-hour days. In simulation time under the continuous working hours assumption, 
if one 8-hour shift is worked per day, an actual three day mission is also a simulated three 
day mission but only 24 hours are worked during those three days. Therefore, the 
duration of the mission must be 24 hours not 72. The simulation automatically changes 
the actual mission duration to the duration based on working hours with this formula: 


Actual Miss lonDur at ionHrs 
2Ahrs / day 


NbrHrsWorked / day 
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Note that if three shifts are worked per day the mission duration stays at 72 hours. The 
other activity durations do not need to be modified as they are already in working hours. 
For example, if 1 2 hours are needed to complete pad processing, no matter whether one, 
two, or three shifts are worked a total of 12 hours will be worked to complete the pad 
processing. The number of days, however, will be 1.5, .75, or .5. 

The Reliability' and Maintainability Model calculates the probability that a 
vehicle successfully completes a mission (no critical failures). Therefore, there are 
actually two mission activities that the vehicle entity can take. It will take one with 
probability equal to one minus the successful completion probability (1 -mission 
reliability), i.e., the vehicle has a critical failure resulting in mission abort and destruction 
of the vehicle In this case the entity is routed to a ‘goon node’; the entity is then 
duplicated so that an entity is immediately routed back to the mission queue as the 
mission will still need to be completed and an entity is routed with duration equal to one 
year back to the vehicle queue as a new vehicle will be manufactured to replace the 
destroyed one. The other mission activity will be taken with probability equal to the 
successful mission probability (mission reliability). If the entity flows through this 
activity, the mission is successfully completed and the entity continues on to the safing 
activity and then to a series of tests to determine which maintenance is to be performed. 

The assign node at the end of the safing activity sets the entity’s 1 1th attribute to 
the current time for calculation of the duration of all on-vehicle maintenance (i.e., the 
maintenance activities which delay the vehicle). It has six conditional branches 
emanating from it. The branches taken depend on which conditions are met. The power, 
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structure, and tanks systems can all be worked on at the same time and must be worked 
on first according to the sequence in figure 4. A pair of branches is for each of these 
systems; the vehicle entity is duplicated so that the same vehicle entity takes one of the 
branches in each pair. Recall that the number of failures is stored as an attribute of the 
entity. The first branch in the pair routes a vehicle entity to the unscheduled maintenance 
repair subroutine if at least one failure has occurred (the entity is then routed to the 
scheduled maintenance subroutine). The second branch in the pair routes the entity 
directly to the scheduled maintenance subroutine if no failures have occurred. Recall 
that scheduled maintenance must always occur. The system maintenance subroutines are 
discussed later. 

When a system's on-vehicle scheduled maintenance is complete, a vehicle entity 
is routed from the system's scheduled maintenance subroutine back to a goon node in the 
Primary Operation and Processing section. It is then routed to the maintenance 
subroutines for the next system in series with the current system. For example, when 
maintenance is done on the power system, an entity is routed to the goon node labeled 
B14 so maintenance can begin on the avionics system. (The labeling of the goon node 
indicates the system just finished with maintenance and the next to be started. For 
example, B14 means system 1 (power) is done and system 4 (avionics) must start.) 
Identical pairs of conditional branches as described in the paragraph above are used to 
route the entity to either unscheduled or scheduled maintenance. When the scheduled 
maintenance on the avionics system is done, the vehicle entity is routed back to another 
goon node for the same conditional branching to determine subsequent maintenance. 
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The life support, mechanical, propulsion, thermal, and auxiliary systems are the 
last systems in series (see figure 4). For each of these systems, a dummy entity is routed 
from its scheduled maintenance subroutine back to one of five queue nodes in the 
Primary Operation and Processing section when the scheduled maintenance is complete. 
This waiting entity signifies that all on-vehicle maintenance is done on all of the systems 
in that particular senes. The vehicle is ready for another mission, i.e., on-vehicle 
maintenance is complete on all of the nine systems, when all five systems have an entity 
waiting in their respective queue node as confirmed by a match node. 

Once a match is made, an entity goes to an assign node to calculate the duration 
of all of the on-vehicle maintenance activities (XX(95) = current time minus time just 
before maintenance starts). Recall that this time is in continuous working hours and is 
changed to days based on the number of hours (shifts) worked per day by dividing the 
duration by either 8, 1 6, or 24 hours for one, two, or three shifts respectively. The 
‘collect node’ displays the mean value and a histogram of the duration times in days on 
the output report. Similarly the turnaround time, which is the elapsed time for a vehicle 
being assigned to one mission and then to being available for the next, is calculated and 
displayed. The entity is then routed back to the vehicle 'queue node’ where it waits to be 
assigned to another mission. 

(2) System Maintenance Subroutines 

There are three maintenance subroutines for each system: on-vehicle 
unscheduled, scheduled, and off-vehicle unscheduled (refer to figure 6). Within each 
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subroutine, maintenance actions are modeled by resources and activities. Modeling 
maintenance this way allows for multiple resources (crews) to be used. 

If at least one failure occurs for a system during the mission, a vehicle entity is 
sent from the Primary Operation and Processing section to the system’s on-vehicle 
unscheduled maintenance subroutine. The attribute storing the number of failures is 
decremented by one at an assign node. Three activities emanate from that node. The 
first activity is always taken by the entity; this activity sends one entity to wait for a 
resource (crew) at an await node. A duplicate entity takes one of the remaining two 
branches depending upon which condition is met. If there is one or more failures 
remaining (attribute value greater than 0), the entity is routed back to the assign node so 
that another entity is sent to the await node. This cycle continues until one entity for 
each failure (attribute value equals 0) has been sent to the await node. Now an entity 
takes the other branch to an await node in the scheduled maintenance subroutine so that 
scheduled maintenance is initiated after the on-vehicle unscheduled maintenance is 
complete. 

The failure entities at the await node seize a resource as soon as one is available. 
The entity then takes one of two activities which simulate the on-vehicle maintenance. 
The first activity is a maintenance action which results in removal of a component when 
no spare is available. In this case, the removed component is repaired immediately and 
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ON-VEHICLE UNSCHEDULED 



FIGURE 6: SYSTEM MAINTENANCE SUBROUTINES 






reinstalled on the vehicle. The probability of this occurring is calculated by the 
Reliability and Maintainability Model and is user input. The duration of this activity is 
the sum of the times to remove, replace, and repair the component. Removing and 
replacing a component is considered a typical on-vehicle unscheduled maintenance 
action; its duration is lognormal with mean equal to the system’s on-vehicle unscheduled 
MTTR value and variance equal to .29 times the mean (Lewellen, 1 8). Repair of the 
component is considered an unscheduled off-vehicle maintenance action; its duration is 
exponential with mean equal to the system’s off-vehicle unscheduled MTTR. When this 
maintenance action is complete, the resources are freed and the entity is terminated. 

The other activity represents all other possible maintenance actions, i.e., spare is 
available or not needed These actions are typical on-vehicle unscheduled maintenance 
actions so their durations are lognormal as described above. The resources are freed at 
the completion of the activity. The entity then takes one of two branches. One branch 
represents a component that was removed, replaced with a spare, and needs to be 
repaired. It sends the entity to the off-vehicle unscheduled maintenance subroutine. The 
other branch represents a completed maintenance action so it sends the entity to a 
terminate node. The probabilities for taking these branches are calculated by the 
Reliability and Maintainability Model and are user input. 

As soon as there are no entities waiting for on-vehicle unscheduled maintenance 
and the user specified number of resources are available, the entity that was sent by the 
unscheduled on-vehicle maintenance subroutine to the await node in the scheduled 
maintenance subroutine seizes the resources so that the on-vehicle scheduled 
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maintenance is performed. The number of resources (crews) that perform scheduled 
maintenance is user input and is a critical variable in determining the minimum number 
of crews as will be described in Chapter 4 The total number of hours to complete the 
on-vehicle scheduled maintenance is calculated by the Reliability and Maintainability 
Model and is user input. The duration of the maintenance activity is calculated 
automatically by the model as the number of hours divided by the number of resources. 
For example if 15 hours (XX(2 1 )) are required to complete scheduled maintenance and 3 
resources (XX(71 )) will perform the maintenance, the duration of the activity will be 
XX(21 )/XX(71)=5 hours. 

When the maintenance activity is complete, the entity is duplicated so there are 
two entities One entity goes back to the Primary Operation and Processing section. It 
goes either to a goon node so maintenance of the next system is initiated or, if the current 
system is the last in the series, to a queue node to wait until all of the systems’ 
maintenance is done. The other entity takes an activity with duration equal to 02 times 
the scheduled maintenance duration and then frees the resources. This activity represents 
the off-vehicle scheduled maintenance. Note that this activity only affects the resource 
utilization and not the vehicle turnaround time. 

Lastly, the entities that are waiting at the off-vehicle unscheduled maintenance 
subroutine seize the resource(s). The off- vehicle unscheduled maintenance is performed 
on the removed components. The duration of the off-vehicle unscheduled maintenance is 
exponential with mean equal to the system’s off-vehicle unscheduled MTTR. Once a 
maintenance action is complete, the resource is freed and the entity is terminated. Again, 
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note that this activity only affects the resource utilization and not the vehicle turnaround 
time. 

One important feature of the code is the definition of the resources. The number 
of resources available can be defined. Also the order in which the resources are to be 
allocated can be specified. Each await node has a unique numerically designated file 
associated with it that stores the entities waiting at the node. These file numbers must be 
specified in the resource definition statement. The order of the file numbers is the order 
that available resources will be allocated. For example, entities waiting at the 
unscheduled maintenance node for the power system (file 1) are allocated resources 
before entities waiting at the scheduled maintenance node (file 2). This feature assures 
that the proper maintenance sequence is followed. 

(3) User Input 

Most of the user input values will be input as global variables into the ‘control 
file’. Global variables are variables that store values input by the user until they are 
specifically changed through reassignment within the ‘network program’. The values for 
the global variables are obtained from the Reliability and Maintainability Model. The 
table on the next page lists the global variable names and the corresponding Reliability 
and Maintainability Model output values. 

The other values a user will most likely input are the number of resources 
available and the number of vehicles created at the start of the simulation. Both of these 
values are entered into the Primary Operation and Processing section of the network file. 
The resource definition block at the beginning of the file lists the resources; the number 
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GLOBAL 

VARIABLES 

RELIABILITY AND 

MAINTAINABILITY PROGRAM OUTPUT 

XX(1)-XX(9) 

System On-vehicle Unscheduled MTTR 

XX( 1 1 )-XX( 19) 

System On-vehicle Unscheduled MTTR Variance* 

XX(2 1 )-XX(29) 

System On-vehicle Scheduled MTTR 

XX(3 1 )-XX(39) 

System Mean Maintenance Actions per Mission 

XX(41)-XX(49) 

System Off-vehicle Unscheduled MTTR 

XX(51)-XX(59) 

System Probability of Removal & No Spare Available 

XX(61)-XX(69) 

System Probability of Removal & Spare Available 

XX(71)-XX(79) 

Number of Crews for Scheduled Maintenance 

NHRS 

Number of Hours Worked per Day 

NDAYS 

Number of Days Worked per Week 

NMISSION 

Number of Missions Planned per Year 

INTEGRATION 

Integration Time in Hours 

PADPROC 

Pad Processing Time in Hours 

MISSION 

Mission Time in Hours 

SAFING 

Safing Time in Hours 

MISRELIABILITY 

Mission Redundant Reliability 

* 

these values calculated by user as sqrt(.29*MTTR) 
Table 1 : Global Variable Definition 


available is in parenthesis. Enter the number of vehicles in the last field of the vehicle 
create node. 

Once all of the necessary input values have been entered. The simulation can be 
run. A detailed description of running the model and reading the output reports for a 
specific set of inputs is presented in Chapter 4. 
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Chapter IV 


Running the Simulation Model 

The minimum number of vehicles and maintenance crews needed to meet the 
required mission rate can be estimated by repeatedly running the Simulation Model. A 
discussion of the information available in the output reports, guidelines for running the 
model, the results of a case study in which the model was run with real data obtained 
from the Reliability and Maintainability Model, and simple user modifications and 
limitations of the model are presented in this chapter. 

A. Output Reports 

An output report is automatically produced for each simulation run (Appendix B). 
The output report provides very useful information for deciding what adjustments to the 
resources need to made. 

The initial statistics at the top of the output report give the mean maintenance 
repair time and the mean turnaround time. Also listed is the number of observations used 
in calculating the mean times, i.e., the number of missions successfully completed. If the 
number of missions completed is less than expected, the number of available resources’ 
for at least one resource was too low. For example, if 28 missions are required each year, 
then 140 missions would be expected in a five year period. Note that if the integration, 
pad processing, mission, and safing times are all deterministic, the turnaround times will 
be equal to a constant (the sum of the integration, pad processing, mission, and safing 
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times) added to the maintenance repair times The histograms of the maintenance repair 
and turnaround times at the end of the report will show this clearly. 

The next output is a set of statistics for all of the await and queue nodes. The 
average wait times for these nodes provide very useful information. The average wait 
time for Q1 is the average time a mission had to wait for a vehicle. If there is a wait time 
(i.e., greater than zero), some missions were not started at their scheduled time. 

Likewise, if there is an average wait time for Q2, some vehicles were available before 
missions were scheduled. The queues labeled Q3-Q7 hold the entities routed to signify 
that on-vehicle maintenance for the last system in a series has been completed. A large 
average wait time for anyone of these nodes means that the systems in the corresponding 
series completed maintenance before other systems and can have resources removed. 
Similarly, a node that has a small average wait time indicates that the systems in that 
series took a long time to complete maintenance. These systems were the last to 
complete maintenance and therefore prolonged the vehicle’s maintenance time. These 
systems may need to have resources added. 

Utilization statistics and the entity counts for the on-vehicle unscheduled, 
scheduled, and off-vehicle unscheduled maintenance activities for each subsystem, for 
the successful missions, and for missions with critical failures are available. The number 
of critical failures is useful for assessing the appropriate number of resources given the 
user’s tolerance of risk. For example, a given number of resources may be sufficient to 
meet the required missions as long as there are 2 or fewer critical failures. If the user 
feels that 3 or more critical failures will not happen, he or she may risk not meeting the 
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mission requirement by using that level of resources even though 3 or more critical 
failures are probabalistically possible. 

Resource utilization statistics are listed on the output report for each of the 
systems The maximum utilization rate may be helpful during the initial stages of 
resource allocation. If an early run of the model is made with a large number of 
resources, not all of the resources will be used. The maximum utilization values can then 
be used for the initial resource (maintenance crews) capacities and then reduced. 

B. Guidelines 

The minimal number of vehicles and crews is determined by running the model 
with a set of inputs, reviewing the output report, adjusting the inputs, and then rerunning 
the model Number of crews available for each system, number of vehicles, and number 
of crews assigned to scheduled maintenance are the inputs to the Simulation Model 
which are repeatedly changed. The number of critical failures has the biggest impact on 
the number of resources required and the ability to meet the needed mission rate. For a 
given crew capacity the destruction of one vehicle can greatly reduce the number of 
completed missions because the turnaround time is not fast enough to complete 
maintenance on the remaining vehicles in time to meet the scheduled mission dates. It is 
best to run the model with the NNRNS field of the GEN statement in the control file set 
at 5 or more so that replications with different random variable seeds (and, therefore, 
varying numbers of critical failures) are obtained each time the model is run. 
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First, the output from the Reliability and Maintainability Model is entered into the 
control File as described at the end of Chapter 3. The number of crews assigned to 
perform scheduled maintenance (the XX(7_) global variables) and the number of 
vehicles is set to one The number of available resources for each system is set at 99. 
Setting the number at 99 assures that all requests for resources will be immediately met 
so that there is no waiting time. The resulting turnaround time will be the shortest 
possible with only one resource performing the scheduled maintenance. 

Once all of the input has been entered, the model is run. Adjustments are then 
made to the inputs based on review of the output reports and user insight. In order to 
understand the affect input changes have on the output, only one of the inputs is changed 
at a time 

With the input described above, the maintenance turnaround times will be very 
short. Therefore, an estimate for the minimum number of vehicles (recall only one 
resource is assigned to scheduled maintenance) is obtained first. The number of vehicles 
is increased by one until the required mission rate is met for each of the replications. If 
the number of completed missions is too low or at least one missions had to wait for a 
vehicle (average wait time for Q1 not equal to 0) the required mission rate is not met. 
This criteria will be used to judge all changes to the inputs. 

The number of available crews is then reduced. The objective is to reduce the 
total number of crews to as few as possible without missing or delaying any missions. 

The number by which to reduce is determined by trial and error, but the average wait 
times for queues labeled Q3-Q7 help identify which systems’ crew availability can be 
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reduced. The systems associated with queues with long average wait times completed 
maintenance before other systems; these systems’ crews can be reduced. For example, if 
only Q3 has a long wait time, the number of Life crews can be reduced. If Q3, Q4, and 
Q5 have long wait times, the number of Power and Avionics crews can be reduced. In 
the former example, only the number of Life crews can be reduced because it is the last 
system in a senes and its previous systems (Power and Avionics) are in series with other 
systems (Mech and Prop) Reducing the number of Power and Avionics crews will 
increase the times the Mech and Prop systems complete maintenance. In the latter 
example, the number of Power and Avionics crews are reduced because all the systems in 
series with these systems ( Life, Mech, and Prop) completed maintenance early. Future 
runs would then indicate if any of the number of crews for the Life, Mech, and Prop 
systems can be reduced as in the first example. 

The mean number of maintenance actions per mission and on-vehicle MTTR 
values can also indicate which systems’ number of available crews can be reduced. 
Systems with few maintenance actions and short MTTR values will complete 
maintenance in less time than other systems. The number of available crews for these 
systems can be reduced. For example, if the Avionics system has .05 maintenance 
actions per mission, on-vehicle unscheduled MTTR equal to 2 hours, and on-vehicle 
scheduled MTTR equal to 1 hour, its maintenance time will be extremely short relative 
to the other systems so its number of available crews can be reduced. Again, the number 
of crews is determined by trial and error. 
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Once the minimum number of available crews has oeen determined, the number 


of crews assigned to perform scheduled maintenance is increased to reduce the scheduled 
maintenance duration. More than one crew should be assigned to the systems with the 
longest on-vehicle scheduled MTTR values. A heuristic method to estimate the number 
assigned is to divide the on-vehicle scheduled maintenance MTTR by the on-vehicle 
unscheduled MTTR. For example, if the Therm system’s unscheduled MTTR is 1 5 hours 
and scheduled MTTR is 60 hours, 4 crews should be assigned (XX(75=4)) so that the 
scheduled maintenance duration is 15 hours (60/4). The rationale for why this method 
works is given on page 39 

If a system’s scheduled maintenance duration is significantly reduced, it will 
complete maintenance before other systems. The crews of some of these systems may 
have to be increased. For example, it may be possible to reduce the number of Therm 
crews available by 3 as the number assigned to perform scheduled maintenance is 
increased from 1 to 4. The Aux system may then become the last system to complete 
maintenance (small average wait time for Q7). One crew may need to be added to the 
Aux system to shorten its maintenance duration so that the desired mission rate is met. 
However, there is still a net reduction of two crews. Again, making changes to the 
number of crews and the allocation of those crews by trial and error is necessary to 
establish the minimal number of crews. 

Once it is determined that additional crew reductions cause the number of 
missions completed to be too low or missions to wait for a vehicle, the minimal number 
of crews for the current number of vehicles is established. The maintenance durations 
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and turnaround times of the vehicle are also minimized. If the maintenance durations are 
short enough, it may be possible to reduce the number of vehicles. The model is run 
again with the number of vehicles reduced by one. If the mission rate is met for all of the 
replications, one less vehicle is needed. If the mission rate is met for all replications 
except those with a large number of failures, the user may accept the risk and decide to 
use one less vehicle knowing there is a real, although small, chance that the mission rate 
will not be met. Alternatively, the user may run the simulation more adding crews and 
changing the number assigned to scheduled maintenance until the mission rate is met for 
all replications. The user has to make tradeoff studies of the cost of one additional 
vehicle and the assurance the mission rate will be met versus the savings one vehicle and 
the cost of additional resources for the assurance that the mission rate will be met. 

C. Case Study 

The simulation model was used to determine the minimum number of crews and 
vehicles needed to meet the mission requirements for a vehicle named “SSTOW”. The 
Reliability and Maintainability Model was run with the vehicle’s design parameters to 
obtain the simulation input (figure 7). This input was entered into the control file 
(Appendix A). The number of working hours, days, and years were also entered into the 
control file. It was assumed that crews would work one 8-hour shift 5 days per week for 5 
years. The input into the control file was NHRS=8, NDAYS=5, and NYRS=5. 

The model was run initially with 99 crews available for each system, 1 crew 
assigned to perform scheduled maintenance, and 1 vehicle. The number of missions 
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SIMULATION INPUT REPORT 
OUTPUT FROM RAM MODEL 

VEHICLE IS SSTCW DATE: 09-12-1994 TIME: 04:41:55 


Subsys 

Maint Actions 

On-Veh MTTR 

Off-veh MTTR 


Per Mission 

in hours 

in hours 

Prob-Rem 

Structural 

3.65186 

2.924435 

.2723976 

.2517892 

Fuel /Ox id Tanks 

- .548793 

10.05298 

0 

. 1845534 

Thermal/Tiles 

2 6. 6948 

13.59266 

0 

. 1456551 

Propulsion 

84.22968 

2.406619 

6.276508 

.2074564 

Power/Electr ical 

2.240062 

9.743523 

.5522666 

.5032578 

Mechanical Sys 

5.752104 

. 6054 5 64 

.2341774 

.3130305 

Avionics 

3 . 1 00063E-02 

1.840963 

. 6621949 

.6565623 

ECS/Life Support 

3.197754 

3.252513 

.3342901 

.4288046 

Auxiliary Systems 

2.67297 

10.05298 

0 

.3230138 


Removal & 

On-Veh 

Off-Veh 

AVG CREW 

Subsys 

No spare 

Sched MTTR 

Sched MTTR 

SIZE 

Structural 

.0105865 

8.664279 

.176822 

2 . 122753 

Fuel/Oxid Tanks 

o,.200002E-03 

17.47582 

.3566493 

2.122753 

Thermal/Tiles 

6.691 42E-03 

41.14294 

.8396518 

4 . 5 

Propulsion 

9.042779E-03 

240.4031 

4 . 906185 

2 .43 

Power/Electr ical 

.0176199 

4.870956 

9 . 940727E-02 

3.547937 

Mechanical Sys 

1 . 254 7 53E-02 

12.25904 

.2501846 

2.122753 

Avionics 

2 . 08 6002E-02 

9. 862685E- 

02 2 . 012793E- 

03 

2.18 

ECS/Life Support 

1 .579549E-02 

9.571705 

. 1953409 

2.317058 

Auxiliary Systems 

.01285 

8.733248 

.1782295 

2.122753 


Launch Reliability .9996665 

Mission Redundant Reliability .9896423 
Integration Time - days 0 

Pad Time - days .5 

Mission Time 72 

Planned missions per Year 28 

Fill rate objective .95 


Figure 7 : Case Study Input 


completed was less than the required 28 missions per year. The number of available 
vehicles had to be increased to 4 to ensure that the required number of missions was met 
with no missions waiting for a vehicle (average wait time for Q1=0) for 7 replications 
(each with different random number seeds for varying numbers of critical failures). The 
mean turnaround time was 15.9 days. One of the output reports is in Appendix B 

The number of crews for each system was then reduced from 99 to the ‘maximum 
number utilized’ listed in the output. The number of crews was further reduced for the 
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systems associated with the queue nodes labeled Q3-Q7 that had long average wait times. 
For example, queue nodes Q3 and Q4 had average wait times over 60 hours. The number 
of crews for the Life and Mech systems was reduced to 1 by repeatedly running the 
model with fewer crews for each run Crews were removed from each system with long 
wait times in this manner. 

Crews were also removed from systems with small average wait times for their 
associated queue node. It is important to note that incurring some wait time at nodes Q3- 
Q7 is not a problem as long as maintenance is completed quickly enough that no 
missions ever have to wait for a vehicle. In other words, reducing the number of crews 
may increase the turnaround time but that is acceptable if the mission rate is still met. 

The following table lists the minimum values for number of crews and the average wait 
times for queue nodes Q3-Q7 with 1 resource assigned to scheduled maintenance, and an 
output report is in Appendix C: 

SYSTEM NBR OF CREWS AVG WAIT TIME 

Power 1 

Structure 1 

Tanks 2 

Avionics 1 

Thermal 25 Q6: 22 hours 

Aux 1 Q7: 2 hours 

Life 1 Q3. 63 hours 

Mech 1 Q4: 67 hours 

Propulsion 16 Q5: 7 hours 

Table 2: Minimum Crews with 4 Vehicles and 1 Scheduled Maintenance Crew 
The turnaround time for this vehicle was 19.8 days, but the mission rate was met for each 
of 7 replications. 
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The number of crews assigned to perform scheduled maintenance on each system 
was then increased to reduce the scheduled maintenance duration. If a system’s 
scheduled maintenance duration is significantly reduced, fewer crews are needed to keep 
that systems mean maintenance duration the same; the duration of the unscheduled 
maintenance can increase by the amount the scheduled maintenance is reduced. Only the 
Tanks, Therm, and Prop systems had more than 1 crew available. (These systems were 
the last to complete maintenance as they had the shortest wait times in the above table.) 
The first estimate for the number of crews to be assigned to perform scheduled 
maintenance was determined by dividing the scheduled maintenance MTTR by the 
unscheduled MTTR. The values for the Tanks, Therm, and Prop systems were calculated 
as 30/10=3, 70/13=5, and 83/2=40. Note that the resulting numbers for the Tanks, 3, and 
the Prop, 40, systems were greater than the number available. Therefore, the numbers 
assigned were the numbers available, 2 and 5. Adjusting the values for number assigned 
and number available for repeated runs of the model resulted in the following minimum 
resource values: 

SYSTEM NBR OF CREWS NBR ASSIGNED 


Power 1 1 

Structure 1 1 

Tanks 3 2 

Avionics 1 1 

Thermal 8 5 

Aux 1 1 

Life 1 1 

Mech 1 1 

Propulsion 5 5 


Table 3: Minimum Crews with 4 Vehicles and Optimum Scheduled Maintenance Crews 
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The number of crews available for the Therm and Prop systems were greatly reduced. 
However, the number of crews available for the Tanks system had to be increased 
because for one replication it became the last system to complete maintenance (Q7=0) 
and caused mission waiting time < Q 1 >0). An output report for these inputs is in 
Appendix D. 

Typically, the final values for number of crews available and assigned can be 
justified. The mean number of maintenance actions for the Therm system is 27. On 
average, 24 unscheduled maintenance actions are completed continuously by the 8 crews 
and then 3 crews complete the remaining unscheduled maintenance actions while 5 
crews perform the scheduled maintenance. In this case, all 8 crews will finish 
maintenance at about the same time since the unscheduled MTTR and the scheduled 
maintenance duration with 5 crews are nearly equal. This observation led to the heuristic 
method for estimating the number of crews assigned described on page 34. 

The turnaround time was reduced to 15.8 hours, nearly the same time for the first 
run with the crew availability set at 99, by assigning more than 1 crew to scheduled 
maintenance. Four vehicles had initially been needed to ensure that the mission rate was 
met; the mission rate had been met with 3 vehicles for all the replications except those 
with 3 critical failures. Therefore, crews were added back into the model and the values 
for the number assigned to scheduled maintenance were adjusted to see if the turnaround 
time could be reduced further so the mission rate could be met with only 3 vehicles. The 
following values for number of crews available and assigned to scheduled maintenance 
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resulted from repeated runs of the model. The turnaround time was reduced to 9 days as 
seen in the output report in Appendix E. 


SYSTEM 

NBR OF CREWS 

NBR ASSIGNED 

Power 

_> 

2 

Structure 

3 

3 

Tanks 

6 

5 

Avionics 

1 

1 

Thermal 

22 

10 

Aux 

3 

2 

Life 

3 

2 

Mech 

2 - 

2 

Propulsion 

10 

8 


Table 4; Minimum Crews and Scheduled Maintenance Crews with 3 Vehicles 
Once the minimal number crews and vehicles has been determined, decisions 
based on cost, risk tolerance, and practicality must be made. The outputs of the 
simulation model can be input into the Life Cycle Costing Model to determine if it is 
cheaper to have 3 vehicles and more crews or 4 vehicles and fewer crews. Fewer crews 
can be used if the user believes that there will not be a lot of critical failures even though 
probabalisticallv possible. The user must establish his or her risk tolerance by examining 
the consequences of not meeting the mission rate. Lastly, the number of crews that can 
actually work on the vehicle concurrently must be considered. For this example, if this 
vehicle is small, 22 Therm crews may not be able to work on the vehicle at the same time 
to perform unscheduled maintenance. Some adjustments to the model can be made to 
obtain additional data that may help the user make resource decisions. 
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D. Modifications and Limitations 

The simulation was designed so that a user with some knowledge of SLAM could 
modify the code so that it more accurately models the real vehicle and its intended 
operation The user may want to modify the times at which vehicles are available, the 
durations of the integration, pad processing, mission, and safing activities, and the 
statistics collected. 

The model has been used to simulate the vehicle over a fixed life cycle with all of 
the vehicles available at the start of the simulation. If the model is to be used to simulate 
vehicles being introduced into service over a period of time, a value is entered into the 
time between creations field of the vehicle create node. For example, if 1 vehicle is to be 
manufactured each year until a total of 4 vehicles are available, the vehicle create node in 
the network file is changed to 

CREATE,2080,0„4. 

Note that 1 year is calculated in working hours. If one 8-hour shift is worked 5 days each 
week, the number of working hours is 

8 hours/day * 5 days/week * 52 weeks/year =2080 hours/year. 

The duration times for the integration, pad processing, mission, and safing 
activities are deterministic. It may be more realistic to model the durations with a 
probability distribution. For example, the mission duration for the case study discussed 
above could be changed from 72 hours to a value determined from a normal distribution 
with mean equal to 72 and variance equal to .29 times the mean. The activity statement 
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in the network file is changed to 

ACT,RNORM(XX( 80),XX( 8 1 )),MISRELIABILITY; 
where the global variables XX(80) and XX(81) are the mean and standard deviation 
calculated by 

XX(80)=MISSION/24*NHRS and XX(81)=SQRT(.29*XX(80)). 

These global variables can be entered into the network file at an assign node prior to the 
activity or into the control file with an 'intlc’ statement. 

Modifications to the model can also be made to calculate additional statistics. If 
the maintenance duration of a specific system is needed, two assign nodes and a collect 
node are added. For example, the mean maintenance duration of the Therm system can 
be calculated by replacing the goon node labeled B25 with an assign node which assigns 
TNOW to an attribute. An assign node and collect node like the ones used to calculate 
the mean vehicle maintenance duration and turnaround time are added before the queue 
node labeled Q6; the label is moved to the assign node. After the scheduled maintenance 
is completed on the Therm system, the entity is routed to the assign node where the time 
stored in the attribute (the time maintenance on the system starts) is subtracted from the 
current time (the time maintenance on the system ends). The entity is then routed to the 
colct node for calculation of the mean Therm maintenance duration and to the queue 
node. 

A limitation of the model is the wait time that is incurred while one or more 
crews wait for the required number of crews to become free so scheduled maintenance 


can start. Each system's scheduled maintenance await node has a global variable XX(7_) 
in the RES/UR field so that an entity at the node must wait until XX(7_) crews are free. 

In reality, if a crew is no longer needed for unscheduled maintenance, it would 
immediately start scheduled maintenance. It would not wait until XX(7_) crews are free. 
However, the inaccuracy introduced into the turnaround times and mission completion 
rate because of this limitation appears to be small and is on the conservative side. As 
discussed earlier, the minimum number of crews and the number assigned to scheduled 
maintenance for each system typically make sense. For example, 6 crews are needed 
with 5 assigned to scheduled maintenance for the Tanks system if only 3 vehicles are 
available. The mean number of unscheduled maintenance actions for the Tanks system 
is 5.3. On average, the 6 crews will be able to start working on all of the maintenance 
actions simultaneously and they will finish around the same time. Then 5 of the crews 
can start the scheduled maintenance. If for a particular run there were 7 unscheduled 
maintenance actions, the 6th crew will start the 7th maintenance action (while the other 5 
crews start the scheduled maintenance). In this case not a lot of wait time was incurred 
while the entity at the scheduled maintenance node waited for 5 crews to become free. 
Similar justifications can be made for other systems’ values for the number of crews 
available and assigned to scheduled maintenance. 
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CHAPTER V 


CONCLUSION 

A description of the SLAM II model designed to simulate the operation and 
processing of proposed space vehicles and a discussion of its use for determining vehicle 
and manpower requirements for a specific vehicle and mission plan has been presented. 
Remaining issues for discussion include model verification and validation and additional 
user insights for effective use of the model. 

A. Model Verification and Validation 

There are two methods to verify that the model operates properly. First, the mean 
turnaround time can be calculated by hand from the input table (figure 7). If only I crew 
is available for each system, all of a system’s unscheduled maintenance will be 
completed in series before the scheduled maintenance. A system’s mean unscheduled 
maintenance duration is calculated by multiplying its maintenance actions per mission by 
its on-vehicle unscheduled MTTR. The resulting values are then added for each 
sequence in figure 3. For example, the unscheduled maintenance duration of the Power, 
Avionics, and Life sequence for the data in figure 7 is 21.3 + .05 + 10.3 or 31.7 hours 
total. The scheduled maintenance durations are also added for each sequence. For 
example, the scheduled maintenance duration for the Tanks and Aux sequence is 29.7 + 
14.8 or 44.5 hours total. Adding a sequence’s unscheduled and scheduled maintenance 
durations results in the total maintenance duration for that sequence. The largest of the 



sequence maintenance durations is the time at which the vehicle completes maintenance. 
For example, the unscheduled and scheduled maintenance durations for the Struc and 
Therm sequence are 363 and 84.7 hours respectively. Therefore, the total maintenance 
duration for this sequence is 363 -r 84.7 or 447.7 hours. This is the longest total 
maintenance duration for a sequence so the vehicle will complete maintenance, on 
average, in 447.7 hours. This time is compared to the mean maintenance duration 
calculated by the model with one vehicle, one crew for each system, and mission 
reliability of 1 . For these inputs, the model computes a mean maintenance duration of 
451 hours which is within 1 percent of 447.7 hours. Therefore, the model operates as 
expected. 

Numerous statistics are calculated and available on the output reports. These 
statistics can also be used to verify that the model is operating properly. For example, the 
output report lists the number of failures as the entity count for the critical failure 
activity. If the critical failure rate is 1-.989 and 140 missions are scheduled, one or two 
critical failures are expected ( 140x(l-.989)=1.54). The number of failures for all runs 
during the case study analysis were always between 0 and 3 (reasonable values). As 
another example, the entity count for a system’s scheduled maintenance activity should 
equal the number of missions successfully completed. This was true for all of the case 
study runs. Examining the statistics in this way can also help in determining if the model 
responds to user input changes as expected. 

The model has not been validated. Validation of a simulation model compares 
the output of the model to actual output’ data. Actual data was not available for this 
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effort. Consequently, it would be very worthwhile to obtain space shuttle maintenance 
personnel data to perform validation. 

B. Additional User Insights 

The critical failure rate is the most significant factor in estimating the number of 
vehicles and crews required to met the planned mission rate. Therefore, it may be more 
insightful to run the model without critical failures (probability of successful mission 
equal to one). Contingency plans can be established to account for the real probability 
that one or more vehicles would have a catastrophic failure. These plans may include 
temporarily bringing in crews from other space vehicle or aircraft programs to shorten 
the maintenance duration or manufacturing an additional vehicle at some established 
future date as a potential replacement for a destroyed vehicle. The user can run the 
simulation to model these contingency plans to determine their effect on meeting the 
mission rate. 

As discussed earlier, the weather has not been explicitly considered in the model. 
In some cases weather may significantly affect the number of resources required to meet 
the mission rate. Code can be added to the model to simulate the effects of weather. 
Weather can be considered as another resource that a vehicle must seize for both launch 
and landing. The availability of the weather resource can be determined by probability 
distribution and ‘alter’ nodes in a separate portion of code. As in the case of critical 
failures, the model can be run without the weather code to establish an ideal number of 
resources and then run with the weather code to establish contingency plans. 
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Lastly, it is important to remember that the simulation model is a tool to be used 
in conjunction with the Reliability and Maintainability Model and Life Cycle Costing 
Model to estimate maintainability and operational parameters. Since the output of the 
Reliability and Maintainability Model is input into the simulation model, it is important 
that the user understand the limitations and assumptions of the Reliability and 
Maintainability Model to avoid making inaccurate interpretations of the simulation 
output. Refer to “Enhanced Methods for Determining Operational Capabilities and 
Support Costs of Proposed Space Systems” (Ebeling) for a discussion of the Reliability 
and Maintainability Model. 
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Appendix A 


; NETWORK FILE 


; START OPERATION AND PROCESSING SECTION 


RESOURCE/POWER (3i , I, 2, 3; 
RESOURCE/ STRUC ( 3 ' ,4,5,6; 
RESOURCE /TANKS (6; , 22, 23, 24; 
RESOURCE/AVION ( 1 1 , 10, 11, 12; 
RESOURCE/ THERM (22) ,7,8,9; 
RESOURCE/AUX (3) ,25,26,27; 
RESOURCE/LIFE (3'. , 13, 14, 15; 
RESOURCE/MECH (21,16,17,18; 
RESOURCE/ PROP (10) , 19, 20,21; 


SYSTEM IDENTIFICATION NUMBER- 1 

Zp 

3 

4 

5 

6 

7 

8 
9 


CREATE; 

ASSIGN, XX (84} = 52 *NDAYS*NHRS/NMISSION; 
ASSIGN, XX (8 5) =NYRS* 52 *NDAYS*NHRS ; 

ACT, XX (85) / 

TERM, 1; 


NBR WORK HRS B/N MISSIONS 
NBR WORK HRS FOR SIMULATION 
SIMULATION DURATION 
STOP SIMULATION 


CREATE, XX (84 ) ; 
ASSIGN, ATRIB(10)=1; 
Q1 QUEUE (28) , , , ,M1; 

CREATE , 0, , , 3 ; 
ASSIGN, ATRIB ( 10) *1; 
Q2 QUEUE (29) , , , ,M1; 

Ml MATCH, 1 0 , Q 1 , Q2 / A 1 ; 


CREATE MISSIONS EVERY XX (84) HRS 

(ENTITIES WAIT FOR VEHICLE) 

CREATE VEHICLES AT TIME=0 

(ENTITIES WAIT FOR MISSION) 

ONLY CONTINUE IF VEHICLE AND MISSION 


A1 ASSIGN, ATR I B ( 1 2 ) =TNOW ; 

ASSIGN, ATRIB ( 1 ) =NPSSN (XX (31) 
ASSIGN, ATRIB (4) =NPSSN (XX (34) 
ASSIGN, ATRIB (7) =NPSSN (XX (37) 
ASSIGN, ATRIB ( 8 ) =NPSSN (XX ( 3 8 ) 
ASSIGN, ATRIB (9) =NPSSN (XX ( 39 ) 
ASSIGN, ATRIB (2) =NPSSN (XX (32) 
ASSIGN, ATRIB (5) =NPSSN (XX ( 35 ) 
ASSIGN, ATRIB (3) =NPSSN(XX (33) 
ASSIGN, ATRIB (6) =NPSSN(XX (36) 


SET START TIME FOR TURN CALC 
) ; NBR FAILURES FOR POWER SYS 

) ; NBR FAILURES FOR AVION SYS 

); NBR FAILURES FOR LIFE SYS 

) ; NBR FAILURES FOR MECH SYS 

) ; NBR FAILURES FOR PROP SYS 

) ; NBR FAILURES FOR STRUC SYS 

) ; NBR FAILURES FOR THERMAL SYS 

) ; NBR FAILURES FOR TANKS SYS 

) ; NBR FAILURES FOR AUX SYS 


ACT, INTEGRATION; 

GOON; 

ACT, PADPROC; 

GOON; 

ACT/29, , 1-MISREL I ABILITY, Cl ; 

ACT / 2 8 , MISS ION/ 2 4 *NHRS , MISRELIABILITY; 

GOON; 

ACT, SAFING; SAFING HRS 


INTEGRATION PROCESSING HRS 
PAD PROCESSING HRS 


CRIT FAIL GO TO Cl 
SUCCESSFUL MISSION 


MAINTENANCE SEQUENCE FOR THE SYSTEMS: 


; 1 2 
4 5 

; 7 8 9 

/ 

; START MAINT ON FIRST SYSTEMS (1, 
ASSIGN, ATRIB (11) =TNOW; 

ACT, , ATRIB ( 1 ) . GE. 1, REP1; 
ACT, , ATRIB (1) . EQ . 0, SCH1 ; 
ACT, , ATRIB (2) . GE . 1,REP2; 


3 ( 1 , 2 & 3 IN PARALLEL, ETC) 

6 

(1, 4&7 IN SERIES, ETC) 

2&3) 

SET START FOR REPAIR TIME CALC 
GO TO REP1 FOR REPAIR AND SCH MAINT 
GO FOR SCH MAINT ONLY (POWER) 

GO TO REP2 FOR REPAIR AND SCH MAINT 
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B14 




336 


547 89 


ACT, , ATRIB ( 2 ) 

. EQ. C, SCH2 ; 

ACT, , ATRIB (3) 

.GE. 1 , REP3 ; 

ACT, , ATRIB 13) 

. EQ. 0, SCH3 ; 

GOON; 

MAINT ON 

ACT, , ATRIB ( 4 ) 

. GE . 1 , REP4 ; 

ACT, , ATRIB (4 ! 

. EQ . C , SCH4 ; 

GOON; 

MAINT ON 

ACT, , ATRIB (5) 

.GE. 1, REP5; 

ACT, , ATRIB (5) 

. EQ . 0 , SCH5 ; 

GOON; 

MAINT ON 

ACT, , ATRIB (6) 

. GE . 1 , REP6; 

ACT, , ATRIB (6) 

. EQ . 0, SCH6; 

GOON; 

MAINT ON SY( 

ACT, , ATRIB (7) 

. GE . 1 , REP7 ; 

ACT, , ATRIB (7) 

. EQ.0,SCH7; 

ACT, , ATRIB (8) 

. GE . 1 , REP8 ; 

ACT, , ATRIB (8) 

. EQ . 0, SCH8 ; 

ACT, , ATRIB (9) 

. GE. 1 , REP9; 

ACT, , ATRIB (9) 

.EQ. 0, SCH9 ; 


GO FOR SCH MAI NT ONLY (STRUC) 

GO TO REP6 FOR REPAIR AND SCH MAINT 
GO FOR SCH MAINT ONLY (TANKS) 

5YSTEM 1 DONE, START SYSTEM 4 
GO TO REP4 FOR REPAIR AND SCH MAINT 
GO FOR SCH MAINT ONLY (AVION) 

SYSTEM 2 DONE, START SYSTEM 5 
GO TO REPS FOR REPAIR AND SCH MAINT 
GO FOR SCH MAINT ONLY (THERMAL) 

SYSTEM 3 DONE, START SYSTEM 6 
GO TO REP 6 FOR REPAIR AND SCH MAINT 
GO FOR SCH MAINT ONLY (AUX) 

rEM 4 DONE, START SYSTEMS 7,8&9 
GO TO REP7 FOR REPAIR AND SCH MAINT 
GO FOR SCH MAINT ONLY (LIFE) 

GO TO REP 7 FOR REPAIR AND SCH MAINT 
GO FOR SCH MAINT ONLY (MECH) 

GO TO REP9 FOR REPAIR AND SCH MAINT 
GO FOR SCH MAINT ONLY (PROP) 


•ONE ENTITY FOR EACH LAST SYSTEM IN A SERIES (5,6,7,8&9) DONE WITH 


; ON-VEHICLE MAINT IS SENT TO A QUEUE TO WAIT UNTIL ALL SYSTEMS DONE, 

LIFE MAINT ON-VEH COMPLETE 
MECH MAINT ON-VEH COMPLETE 
PROP MAINT ON-VEH COMPLETE 
THERM MAINT ON-VEH COMPLETE 
AUX MAINT ON-VEH COMPLETE 
Q7/A2; ALL VEHICLE MAINT DONE 


Q3 
04 
Q5 
Q6 
Q 7 
M2 


QUEUE (30) , , , , M2; 
QUEUE (31) , , , ,M2; 
QUEUE (32) , , , ,M2; 

QUEUE (33) , , , ,M2; 

QUEUE (34) , , , ,M2; 
MATCH, 10, Q3, Q4, Q5,Q6, 


•CALC. STATISTICS FOR ON-VEHICLE MAINT DURATION AND TURN TIME IN DAYS 
; BY DIVIDING DURATION IN HOURS BY NHRS (NBR HRS WORKED/ DAY) . 

A2 ASSIGN, XX (95) =TNOW-ATRIB (11) ,XX(95) =XX(95) /NHRS; 

COLCT , XX ( 9 5 ) , MEAN MAINT TIME IN DAYS, 10/6/2; 

ASSIGN, XX (96) =TNOW-ATRIB (12) , XX ( 96) =XX ( 96) /NHRS; 

COLCT, XX (96) , MEAN TURN TIME IN DAYS, 10/10/2; 


•VEHICLE READY FOR ANOTHER MISSION, ROUTE ENTITY BACK TO VEHICLE QUEUE 
ACT, , ,Q2; 


; FOR CRITICAL FAILURES, MISSION STILL NEEDED SO 1 ENTITY ROUTED TO 
;MISS ION QUEUE AND NEW VEHICLE MADE SO 1 ENTITY ROUTED TO VEHICLE 
; QUEUE WITH DURATION OF 1 YEAR. 

Cl GOON; 

ACT, , ,Q1; 

ACT, 52*NDAYS*NHRS, ,Q2; 

•END OPERATION AND PROCESSING SECTION 


•START SYSTEM MAINTENANCE SECTION 

; EACH OF THE 9 SYSTEMS HAS ITS OWN MAINTENANCE SUBROUTINES: 
; -ON-VEHICLE UNSCHEDULED MAINT 
; -ON-VEHICLE SCHEDULED MAINT 
; -OFF-VEHICLE UNSCHEDULED 
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; POWER ON-VEHICLE UNSCHEDULED MAINT 

REP1 ASSIGN, ATR IB ( 1 ) =ATRIB ( 1 ) -1 ; REMAINING NBR OF FAILURES 

ACT , , , R1 ; 1 ENTITY REPRESENTING A FAILURE TO R1 

ACT , , ATRIB ( 1 ) . GE . 1 , REP1 ; BACK TO REP1 IF MORE FAILURES REMAIN 

ACT, , ATRIB (1) . EQ.C, SCH1; - OR- 1 ENTITY TO SCHED AWAIT NODE 

R1 AWAIT (1) , POWER; START MAX NT WHEN RESOURCE AVAILABLE 

ACT/ 1 , RLOG (XX ( 1 ) , XX (11)) +EXPON (XX (41 ) ) , XX (51 ) , TI ; NO SPARE AVAIL 
ACT / 1 , RLOG ( XX ( 1 ) , XX { 1 1 ) ) , 1 -XX (51) ; ON-VEH UNSCHED1 
FREE , POWER ; 

ACT, , XX ( 61 ) , OFF1 ; SEND ENTITY FOR MAINT OF REMOVED COMPONENT 
ACT, , 1-XX (61 ) ; NO ADDITIONAL MAINT REQUIRED, TERM ENTITY 

TERM; 

Tl FREE, POWER ; 

TERM; 

; POWER ON- VEHICLE SCHEDULED MAINT 

SCH1 AWAIT (2) , POWER/XX (71) ; START WHEN XX (71) CREWS AVAIL 

ACT/2, XX (21) /XX (71); ON-VEH SCH1 MAINT 

GOON; 

ACT,,, 314; POWER ON-VEHICLE MAINT DONE, START NEXT SYSTEM 
ACT, .02*XX (21) ; • OFF-VEH SCH1 MAINT 

FREE, POWER/XX (71) ; 

TERM; 

; POWER OFF-VEHICLE UNSCHEDULED MAINT 
OFF1 AWAIT (3) , POWER; 

ACT/3, EXP (XX (4 1) ) ; OFF-MAINT1 

FREE, POWER; 

TERM; 

; AVIONICS ON- VEHICLE UNSCHEDULED MAINT 
REP 4 ASSIGN, ATRIB (4) =ATRIB (4) -1; 

ACT, , ,R4; 

ACT, , ATRIB (4) . GE . 1, REP4; 

ACT, , ATRIB (4) .EQ,0,SCH4; 

R4 AWAIT (10) , AVION; 

ACT / 1 0 , RLOG (XX ( 4 ) , XX (14)) +EXPON (XX ( 44 ) ) , XX ( 54 ) , T4 ; NO SPARE AVAIL 
ACT / 1 0 , RLOG ( XX (4) , XX ( 1 4 ) ) , 1- XX (54) ; ON-VEH UNSCHED4 
FREE, AVION; 

ACT, ,XX (64) ,OFF4; SEND ENTITY FOR MAINT OF REMOVED COMPONENT 

ACT, , 1-XX (64) ; NO ADDITIONAL MAINT REQUIRED, TERM ENTITY 

TERM 

T 4 FREE, AVION; 

TERM; 

; AVI 0 ICS ON-VEHICLE SCHEDULED MAINT 

SCH4 AWAIT (11) , AVION/XX (74) ; START WHEN XX (74) CREWS AVAIL 

ACT/ 11, XX (24) /XX (74) ; ON-VEH SCH4 MAINT 

GOON; 

ACT , , , B47 8 9 ; AVIONICS ON-VEHICLE MAINT DONE, START NEXT SYSTEM 
ACT , . 02*XX (24 ) ; OFF-VEH SCH4 MAINT 

FREE, AVION/XX (74) ; 

TERM; 

; AVIONICS OFF-VEHICLE UNSCHEDULED MAINT 
OFF4 AWAIT (12) , AVION; 

ACT/ 12, EXP (XX (44) ) ; OFF-MAINT4 

FREE, AVION; 

TERM; 

/ 

; LIFE ON-VEHICLE UNSCHEDULED MAINT 
REP7 ASSIGN, ATRIB (7) =ATRIB(7) -1; 

ACT, , ,R7; 

ACT, , ATRIB (7) . GE . 1 , REP7 ; 

ACT, , ATRIB (7) .EQ.0,SCH7; 
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R7 AWAIT (13) , L I FE ; 

ACT/13, RLOG (XX (7) , XX (17) ) +EXPON (XX (47! ) , XX (57) , T7; NO SPARE 
ACT/13, RLOG (XX (7) , XX (17) ) , 1-XX (57) ; ON-VEH UNSCFED7 
FREE LIFE* 

ACT,) XX (67) ,OFF7; SEND ENTITY FOR MAINT OF REMOVED COMPONENT 

ACT, , 1-XX (67) ; NO ADDITIONAL MAINT REQUIRED, TERM ENTITY 

TERM 

T7 FREE, LIFE; 

TERM; 

; LIFE ON-VEH ICLE SCHEDULED MAINT 

SCH7 AWAIT ( 14 ) , LIFE/XX (77) ; START WHEN XX (77) CREWS AVAIL 

ACT/ 14, XX (27) /XX ( 77 ) ; ON-VEH SCH7 MAINT 

GOON 

ACT, , , Q3 ; LIFE SYSTEM & ALL ON-VEH MAINT IN THIS SERIES 

DONE 

ACT, .G2*XX (27) ; OFF-VEH SCH7 MAINT 

FREE, LIFE/XX (77) ; 

TERM; 

; LIFE OFF-VEHICLE UNSCHEDULED MAINT 
OFF7 AWAIT (15) , LIFE; 

ACT/15, EXP (XX (47) ) ; 0FF-MAINT7 

FREE, LIFE; 

TERM; • 

; MECHANICAL ON-VEHICLE UNSCHEDULED MAINT 
REP8 ASSIGN, ATRIB (8) =ATRIB (8) -1; 

ACT, , , R8; 

ACT, , ATRIB ( 8 ) .GE.1,REP8; 

ACT, , ATRIB (8) .EQ.0,SCH8; 

R8 AWAI T ( 1 6 ) , MECH ; 

ACT/ 1 6, RLOG (XX ( 8 ) , XX (18)) +EXPON (XX (48) ) , XX ( 58 ) , T8 ; NO SPARE 
ACT/ 1 , RLOG (XX ( 8 ) , XX ( 18 ) ) , 1-XX (58) ; ON-VEH UNSCHED8 
FREE, MECH; 

ACT, , XX ( 68 ) , OFF8 ; SEND ENTITY FOR MAINT OF REMOVED COMPONENT 

ACT, , 1-XX (68) ; NO ADDITIONAL MAINT REQUIRED, TERM ENTITY 

TERM 

T8 FREE, MECH; 

TERM; 


; MECHANICAL ON-VEHICLE SCHEDULED MAINT 


SCH8 

AWAIT (17) , MECH/XX (78) ; 
ACT/17, XX(28) /XX (78 ) ; 

START WHEN XX (78) CREWS AVAIL 
ON-VEH SCH8 MAINT 


GOON; 

ACT, , , Q4 ; MECH SYSTEM 

& ALL ON-VEH MAINT IN THIS SERIES 

DONE 

ACT, . 02*XX (28) ; 
FREE, MECH/XX (78) ; 

OFF-VEH SCH8 MAINT 


TERM; 



; OFF-VEHICLE UNSCHEDULED MAINT 


OFF8 AWAI T ( 1 8 ) , MECH ; 

ACT/18, EXP (XX (48) ) ; OFF-MAINT8 

FREE, MECH; 

TERM; 

•PROPULSION ON-VEHICLE UNSCHEDULED MAINT 
REP 9 ASSIGN, ATRIB (9) =ATRIB (9) -1 ; 

ACT, , , R9; 

ACT, , ATRIB (9) .GE.1,REP9; 

ACT, , ATRIB (9) .EQ.0,SCH9; 

R9 AWAIT ( 19) , PROP; 

ACT/ 19, RLOG (XX ( 9) , XX ( 19) ) +EXPON (XX (49) ) , XX (59) , T9; NO SPARE 
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ACT/19, RLOG JXX (9) ,XX ( 19); , 1-XX (59) ; ON-VEH UNSCHED9 
FREE, PROP; 

ACT , , XX ! 6 9 ) , C FF9 ; SEND ENTITY FOR MAINT OF REMOVED COMPONENT 

ACT, , 1-XX { 69) ; NO ADDITIONAL MAINT REQUIRED, TERM ENTITY 

TERM 

T9 FREE, PROP; 

TERM; 

; PROPULSION ON-VEHICLE SCHEDULED MAINT 

SCH9 AWAIT (20) , PROP/XX (79) ; START WHEN XX (79) CREWS AVAIL 

ACT/20, XX (29) /XX (79) ; ON-VEH SCH9 MAINT 

GOON; 

ACT, , , Q5; PROP SYSTEM & ALL ON-VEH MAINT IN THIS SERIES 

DONE 

ACT, . 02*XX (29) ; OFF-VEH SCH9 MAINT 

FREE, PROP/XX (79) ; 

TERM; 

; PROPULSION OFF- VEHICLE UNSCHEDULED MAINT 
OFF9 AWAIT (21) , PROP; 

ACT/21 , EXP (XX (49) ) ; OFF-MAINT9 

FREE, PROP; 

TERM; 

; STRUCTURE ON- VEHICLE UNSCHEDULED MAINT 
REP2 ASSIGN, ATRIB (2) =ATRIB (2) - 1 ; 

ACT, , , R2; 

ACT, , ATRIB (2) . GE . 1 , REP2 ; 

ACT, , ATRIB (2) . EQ. 0, SCH2; 

R2 AWAIT ( 4 ) , STRUC; 

ACT/4, RLOG (XX (2) , XX (12) ) +EXPON(XX (42) ) ,XX(52) ,T2; NO SPARE 
ACT/4, RLOG (XX (2) , XX (12) ), 1-XX (52) ; ON-VEH UNSCHED2 
FREE, STRUC; 

ACT, , XX ( 62 ) , OFF2 ; SEND ENTITY FOR MAINT OF REMOVED COMPONENT 

ACT, , 1-XX (62) ; NO ADDITIONAL MAINT REQUIRED, TERM ENTITY 

TERM 

T2 FREE, STRUC ; 

TERM; 

; STRUCTURE ON-VEHICLE SCHEDULED MAINT 

SCH2 AWAIT (5) , STRUC/XX (72) ; START WHEN XX(72) CREWS AVAIL 

ACT/ 5, XX (22) /XX (72) ; ON-VEH SCH2 MAINT 

GOON; 

ACT,,,B25; STRUC ON-VEHICLE MAINT DONE, START NEXT SYSTEM 

ACT, .02*XX (22) ; OFF-VEH SCH2 MAINT 

FREE, STRUC/XX (72) ; 

TERM; 

f 

; STRUCTURE OFF-VEHICLE UNSCHEDULED MAINT 
OFF2 AWAIT ( 6) , STRUC; 

ACT/6, EXP (XX (42) ) ; OFF-MAINT2 

FREE, STRUC; 

TERM; 

r 

; THERMAL/TILES ON-VEHICLE UNSCHEDULED MAINT 
REPS ASSIGN, ATRIB (5) =ATRIB(5) -1; 

ACT, , ,R5; 

ACT, , ATRIB (5) .GE.1,REP5; 

ACT, , ATRIB (5) .EQ.O, SCH5; 

R5 AWAIT ( 7 ) , THERM; 

ACT/ 7, RLOG (XX ( 5) , XX ( 15) ) +EXPON (XX (45) ) , XX (55) , T5; NO SPARE 
ACT/7, RLOG (XX (5) , XX (15) ), 1-XX (55) ; ON-VEH UNSCHED5 
FREE, THERM; 

ACT, , XX (65) , OFFS; SEND ENTITY FOR MAINT OF REMOVED COMPONENT 
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NO ADDITIONAL MAINT REQUIRED, TERM ENTITY 


ACT, , L-XX ! 65) ; 
TERM 


T5 FREE, THERM; 


TERM; 

; THERMAL/ TILES CN-VEHICLE SCHEDULED 
SCH5 AWAIT ( 8 i , THERM/XX (75) ; 

ACT/8, XX(25) /XX (75) ; 

GOON; 

ACT, , , Q6; THERM SYSTEM 

DONE 

ACT, . 02*XX (25, ; 

FREE, THERM/XX (75) ; 


MAINT 

START WHEN XX (75) CREWS AVAIL 
ON-VEH SCH5 MAINT 

& ALL ON-VEH MAINT IN THIS SERIES 

OFF-VEH SCH5 MAINT 


TERM; 

; THERMAL/TILES OFF-VEHICLE UNSCHEDULED MAINT 
OFF5 AWAIT ( 9) , THERM; 

ACT/9, EXP (XX (45) ) ; OFF-MAINT5 

FREE, THERM; 

TERM; 


•FUEL/OXIDE TANKS ON-VEHICLE UNSCHEDULED MAINT 
REP3 ASSIGN, ATRIB ( 3) =ATRIB (3) -1; 


R3 


ACT, , , R3 ; 

ACT, , ATRIB (3) . GE. 1, REP3; 

ACT, , ATRIB (3) .EQ.0,SCH3; 

AWAIT (22) , TANKS; 

ACT/22 , RLOG (XX ( 3) , XX (13)) +EXPON (XX (43) ) , XX (53) , T3 ; NO SPARE 
ACT/22, RLOG (XX ( 3) , XX ( 13) ) , 1-XX (53) ; ON-VEH UNSCHED3 


SEND ENTITY FOR MAINT OF REMOVED COMPONENT 
NO ADDITIONAL MAINT REQUIRED, TERM ENTITY 


FREE, TANKS; 

ACT, , XX (63) , OFF3 ; 

ACT, , 1-XX (63) ; 

TERM 

T3 FREE, TANKS; 

t^ERM . 

; FUEL /OXIDE’ TANKS ON-VEHICLE SCHEDULED MAINT 

SCH3 AWAIT (23) , TANKS /XX ( 73) ; START WHEN XX (73) CREWS AVAIL 

ACT/23, XX (23) /XX (73) ; ON-VEH SCH3 MAINT 

ACT^! , B36 ; TANKS ON-VEHICLE MAINT DONE, START NEXT SYSTEM 

ACt/.02*XX(23) ; OFF-VEH SCH3 MAINT 

FREE, TANKS /XX (73) ; 


TERM; 


; FUEL/OXIDE TANKS OFF- VEHICLE UNSCHEDULED MAINT 
OFF3 AWAIT (24), TANKS ; 

ACT/24, EXP (XX (43) ) ; OFF-MAINT3 

FREE, TANKS; 

TERM; 


’•AUXILIARY SYSTEMS ON-VEHICLE UNSCHEDULED MAINT 
REP6 ASSIGN, ATRIB (6) =ATRIB (6) -1; 


R6 


ACT, , , R6; 

ACT, , ATRIB (6) .GE.1,REP6; 

ACT, , ATRIB (6) ,EQ.0,SCH6; 

AWAIT (25) ,AUX; 

ACT/25, RLOG (XX ( 6 ) , XX (16)) +EXPON (XX (46) ),XX(56),T6; 
ACT/25, RLOG (XX ( 6) , XX (16) ), 1-XX (56) ; ON-VEH UNSCHED6 


NO SPARE 


SEND ENTITY FOR MAINT OF REMOVED COMPONENT 
NO ADDITIONAL MAINT REQUIRED, TERM ENTITY 

TERM 

T6 FREE , AUX ; 


ACT, , XX (66) , OFF6 ; 
ACT, , 1-XX (66) ; 
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TERM; 

/AUXILIARY SYSTEMS ON-VEHICLE 
SCH6 AWAIT (26) , AUX/XX (76) ; 

ACT/26, XX (26) /XX (76) ; 
GOON; 

ACT , , , Q7 ; THERM 

DONE 


SCHEDULED MAINT 

START WHEN XX (76) CREWS AVAIL 
ON-VEH SCH6 MAINT 

SYSTEM & ALL ON-VEH MAINT IN THIS SERIES 


ACT, . 02*XX (26) ; OFF-VEH SCH6 MAINT 

FREE, AUX/XX (76) ; 

TERM; 

; AUXILIARY SYSTEMS OFF- VEHICLE UNSCHEDULED MAINT 
OFF6 AWAIT (27) ,AUX; 

ACT/27, EXP (XX ( 46) ) ; OFF-MAINT6 

FREE, AUX; 

TERM; 

ENDNETWORK; 

; END SYSTEM MAINTENANCE SECTION 


54 



CNTROL FILE (USER INPUT SECTION) 


GEN, DONOHUE, NAS AS IM, 8/29/1994, 6, Y, Y, Y/Y, Y, Y/l , 132; 

LIMITS, 34,13, 650; 

T OUI VALENCE /XX (80) , NHRS/XX (81 ) , NDAYS/XX (82 ) , NYRS/XX (83) , NMISS ION; 
EQUIVALENCE/XX (90) , INTEGRATION/XX ( 91 ) , PADPROC/XX ( 92 ) , MISSION; 
EQUIVALENCE /XX (93 ) , SAFING/XX (94 ) , MISRELIABILITY; 


THE GLOBAL VARIABLES BELOW, 

LEAST SIGNIFICANT DIGIT IDENTIFIES THE SYSTEM: 


9 

; FOR 
; THE 
; 1 POWER 

; 2 STRUCTURAL 
; 3 FUEL/ OXID TANKS 
; 4 AVIONICS 
; 5 THERMAL/ TILES 


6 AUXILIARY 

7 ECS/LIFE SUPPORT 

8 MECHANICAL SYS 

9 PROPULSION 


•THE MOST SIGNIFICANT DIGIT IDENTIFIES THE INPUT DATA TYPE: 
; 0 ON-VEH MTTR 
; 1 ON-VEH STD DEV 

; 2 ON-VEH SCHED MTTR 
; 3 MAINT ACTIONS PER MISSION 
; 4 OFF-VEH MTTR 
; 5 REMOVAL & NO SPARE 
; 6 PROB-REM 


ON-VEHICLE UNSCHEDULED MTTR 
INTLC, XX (1)=9. 743523, XX (2 ) =2 . 9244 35, XX ( 3) =10 . 05298 ; 
INTLC, XX ( 4 ) =1 . 840963, XX (5) =13 . 59266, XX ( 6) =10 . 05298 ; 
INTLC , XX (7) =3.252513, XX (8) =. 6054564, XX (9) =1.683705; 


•ON- VEHICLE MTTR STANDARD DEVIATION=SQRT ( . 29*MTTR) 
INTLC, XX (11) =1 . 68096, XX (12) =. 920916, XX (13) =1.70744 ; 
INTLC, XX (14) = . 73067, XX ( 15) =1 . 98541, XX ( 16) =1 . 70744; 

INTLC, XX ' 17 ) = . 97 1 199, XX ( 18) =.4 19025, XX (19) =.698766; 


; ON-VEHICLE SCHEDULED MTTR 

INTLC,XX(21)=8.280173,XX(22)=14. 72847, XX (23) =29.70727; 
INTLC, XX (24) = . 167 6565, XX (2 5) =69 . 93918, XX (26) =14 . 84571 ; 
INTLC, XX (27) =16. 27 101, XX (28 ) =20. 83924, XX (29) =82. 83476; 

; MAINTENANCE ACTIONS PER MISSION 

INTLC, XX (31)=2.240062, XX (32)=2. 65186, XX (33)=5. 348793; 
INTLC, XX (34)=. 0310006, XX (35)=26. 6948, XX ( 36) =2 . 67297 ; 
INTLC, XX (37) =3. 1977 54, XX (38) =3. 7 52 104, XX (39) =17. 0731; 

OFF-VEHICLE UNSCHEDULED MTTR 
INTLC, XX (41)=.5522666,XX(42)=.2723976,XX(43)=0; 

INTLC, XX (44) =.6621949, XX (4 5) =0, XX (4 6) =0; 

INTLC, XX (47) =.3342901, XX (48 >=.2341774, XX (49) =4. 102313; 

; REMOVAL RATE WITH NO SPARE AVAILABLE 

INTLC, XX (51) =.0352398, XX (52 >=.021173, XX (53) =.0164; 

INTLC, XX (54)=. 04172, XX (55)=. 0133828, XX (56)=. 0257; 
INTLC, XX (57) =. 031 591, XX (58 )=. 0250951, XX (59) =.0274691; 


PROBABILITY OF REMOVAL WITH SPARE AVAILABLE 
INTLC, XX (61)=.464468,XX(62)=.2354174,XX(63)=.173158; 
INTLC, XX (64) =.60123, XX (65) =.136939, XX (66) =.300898; 

INTLC, XX (67) =.39727, XX (68) =.291749, XX (69) =.328412; 
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; NUMBER OF CREWS FOR SCHEDULED MAINTENANCE 
INTLC , XX ( 7 1 1 =2 , XX ( 7 2 ) = 3 , XX { 7 3 ) =5 ; 

7NTLC,XX (74) =1,XX(75)=10,XX ( 7 6 ) =2 ; 

INTLC, XX (77) =2, XX <78: =2, XX (79) =8; 

INTLC, NHRS=8,NDAYS = 5, NYRS=5, NMISSION=28, INTEGRATIONS; 

INTLC, PADPROC=12 , MISS ION=72, 5AFING=0, MISRELIABILITY= . 9896423; 

f 

NETWORK; 

INITIALIZE, , , Y; 

FIN; 


The output report for the input as specified in this appendix is in Appendix E. 
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Appendix B 


Output with 99 crews available for each system, 4 vehicles, and 1 crew assigned to 

scheduled maintenance for each system. 

SLAM I* I SUMMARY REPORT 


SIMULATION PROJECT NASASIM BY DONOHUE 


DATE 8/29/1994 
CURRENT TIME 

. LQ4GE+G5 


RUN NUMBER 

1 OF 

7 

STATISTICAL ARRAYS CLEARED AT TIME 

. OOOOE+OO 



"*STAT 

ISTICS FOR VARIABLES BASED ON 

OBSERVATION* * 



MEAN STANDARD 

COEFF. OF 

MINIMUM 

MAXIMUM 

NO. OF 


VALUE DEVIATION 

VARIATION 

VALUE 

VALUE 

OBS 

MEAN MAINT TIME 

. 114E+02 . 32 IE-04 

.282E-05 

. 114E+02 

. 114E+02 

139 

MEAN TURN TIME I 

. 159E+02 .321E-04 

. 2 02E-05 

. 159E+02 

. 159E+02 

139 


* * FILE STATISTICS** 


FILE 



AVERAGE 

STANDARD 

MAXIMUM 

CURRENT 

AVERAGE 

NUMBER 

LABEL/TYPE 

LENGTH 

DEVIATION 

LENGTH 

LENGTH 

WAIT TIME 

1 

R1 

AWAIT 

.000 

.000 

1 

0 

.000 

2 

SCH1 

AWAIT 

.000 

.000 

I 

0 

.000 

3 

OFF1 

AWAIT 

.000 

.000 

1 

0 

.000 

4 

R2 

AWAIT 

.000 

.000 

1 

0 

.000 

5 

SCH2 

AWAIT 

.000 

.000 

1 

0 

.000 

6 

OFF2 

AWAIT 

.000 

.000 

1 

0 

.000 

7 

R5 

AWAIT 

.000 

.000 

1 

0 

.000 

8 

SCH5 

AWAIT 

.000 

.000 

1 

0 

.000 

9 

OFF5 

AWAIT 

.000 

.000 

1 

0 

.000 

10 

R4 

AWAIT 

.000 

.000 

1 

0 

.000 

11 

SCH4 

AWAIT 

.000 

.000 

1 

0 

.000 

12 

OFF4 

AWAIT 

.000 

.000 

1 

0 

.000 

13 

R7 

AWAIT 

.000 

.000 

1 

0 

.000 

14 

SCH7 

AWAIT 

. 000 

.000 

1 

0 

.000 

15 

OFF7 

AWAIT 

.000 

.000 

1 

0 

.000 

16 

R8 

AWAIT 

.000 

.000 

1 

0 

.000 

17 

SCH8 

AWAIT 

.000 

.000 

1 

0 

.000 

18 

OFF8 

AWAIT 

. 000 

.000 

1 

0 

. 000 

19 

R9 

AWAIT 

.000 

.000 

1 

0 

. 000 

20 

SCH9 

AWAIT 

. 000 

.000 

1 

0 

.000 

21 

0FF9 

AWAIT 

.000 

. 000 

1 

0 

.000 

22 

R3 

AWAIT 

.000 

.000 

1 

0 

.000 

23 

SCH3 

AWAIT 

.000 

.000 

1 

0 

.000 

24 

OFF3 

AWAIT 

. 000 

.000 

1 

0 

. 000 

25 

R6 

AWAIT 

. 000 

.000 

1 

0 

.000 

26 

SCH6 

AWAIT 

. 000 

.000 

1 

0 

.000 

27 

0FF6 

AWAIT 

.000 

.000 

1 

0 

.000 

28 

Q1 

QUEUE 

.000 

.000 

1 

0 

.000 

29 

Q2 

QUEUE 

2.091 

.608 

3 

3 

150.982 

30 

Q3 

QUEUE 

.891 

.313 

2 

1 

66.185 

31 

Q4 

QUEUE 

.829 

.376 

1 

1 

61.617 

32 

Q5 

QUEUE 

.000 

.000 

1 

0 

.000 

33 

Q6 

QUEUE 

.088 

.284 

1 

0 

6.615 

34 

Q7 

QUEUE 

.625 

.484 

1 

0 

46.730 

35 


CALENDAR 

13.489 

11.275 

55 

6 

2.037 
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’* REGULAR ACTIVITY STATISTICS** 


ACTI\ 

r ITY 

AVERAGE 

STANDARD 

MAXIMUM 

CURRENT 

ENTITY 


INDEX/LABEL 

UTILIZATION 

DEVIATION 

UTIL 

UTIL 

COUNT 


1 

ON-VEH UNSCH 

.3237 

.9638 

13 

0 

844 

— 

O 

it 

ON-VEH SCHI 

.1115 

.3147 

1 

0 

140 

* 

3 

0FF-MAINT1 

.0069 

.0849 

2 

0 

149 


4 

ON-VEH UNSCH 

.0998 

.5490 

8 

0 

352 


3 

ON-VEH SCH2 

. 1983 

.3987 

1 

0 

140 

S 

6 

OFF-MAINT2 

. 0019 

.0453 

2 

0 

70 

m 

7 

ON-VEH UNSCH 

4.8888 

10.0694 

41 

0 

3747 


8 

ON-VEH SCH5 

.9370 

.2459 

2 

1 

139 

— 

9 

OFF-MAINT5 

.0000 

,0000 

1 

0 

532 


10 

ON-VEH UNSCH 

.0015 

.0392 

1 

0 

6 


11 

ON-VEH SCH4 

.0023 

.0475 

1 

0 

14 0 


12 

OFF-MAINT 4 

.0005 

.0222 

1 

0 

4 


13 

ON-VEH UNSCH 

.1359 

. 6929 

9 

0 

442 

w 

14 

ON-VEH SCH7 

.2190 

.4136 

1 

0 

140 


15 

OFF-MAINT7 

.0047 

.0720 

3 

0 

164 


16 

NO SPARE 

.0005 

.0233 

2 

0 

7 

— 

17 

ON-VEH SCH8 

.2805 

.4493 

1 

0 

140 

■ 

18 

OFF-MAINT8 

.0036 

.0658 

3 

0 

160 


19 

ON-VEH UNSCH 

.4196 

2.4065 

30 

0 

2468 



20 

ON-VEH SCH9 

1 .1100 

.3273 

2 

1 

139 


21 

OFF-MAINT9 

.3200 

1.0082 

10 

0 

831 

■ 

22 

ON-VEH UNSCH 

. 6983 

1.8777 

12 

0 

735 


23 

ON-VEH SCH3 

.3999 

.4899 

1 

0 

140 


24 

OFF-MAINT3 

.0000 

.0000 

1 

0 

130 


25 

ON-VEH UNSCH 

.3703 

1.0583 

7 

2 

381 


26 

ON-VEH SCH6 

. 1992 

.3994 

1 

1 

139 


27 

OFF-MAINT6 

.0000 

.0000 

1 

0 

108 



28 

SUCCESSFUL M 

. 3231 

.4677 

1 

0 

140 

m 

29 

CRIT FAIL GO 

. 0000 

.0000 

1 

0 

1 



* * RESOURCE STATISTICS** 




=== 


RESOURCE 

RESOURCE 

CURRENT 

AVERAGE STANDARD MAXIMUM CURRENT 

m 

NUMBER 

LABEL 

CAPACITY 

UTIL DEVIATION UTIL UTIL 


1 

POWER 

99 

.41 

1.141 

9 0 


o 

£. 

STRUC 

99 

.30 

,795 

9 0 


3 

TANKS 

99 

1 .11 

2.143 13 0 

m 

4 

AVION 

99 

.00 

.067 

2 0 


5 

THERM 

99 

5.84 

10.095 42 1 


6 

AUX 

99 

.57 

1.368 

8 3 

— 

7 

LIFE 

99 

.36 

.943 10 0 

■ 

8 

MECH 

99 

.32 

.608 12 O 


9 

PROP 

99 

1 . 87 

2.978 32 1 

— 







a 

RESOURCE 

RESOURCE 

CURRENT 

AVERAGE 

MINIMUM 

MAXIMUM 


NUMBER 

LABEL 

AVAILABLE 

AVAILABLE 

AVAILABLE 

AVAILABLE 


1 

POWER 

99 

98.5864 

90 

99 

- 

2 

STRUC 

99 

98.6960 

90 

99 


3 

TANKS 

99 

97.8938 

86 

99 

- = 

4 

AVION 

99 

98.9957 

97 

99 


5 

THERM 

98 

93.1554 

57 

99 


6 

AUX 

96 

98.4264 

91 

99 


7 

LIFE 

99 

98.6359 

89 

99 


8 

MECH 

99 

98.6791 

87 

99 


9 

PROP 

98 

97.1283 

67 

99 
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* * HISTOGRAM NUMBER 1 * * 


MEAN MAINT TIME 


03S 

RE LA 

UPPER 




FREQ 

FREQ 

CELL LIM 

0 

20 40 60 80 

100 




«- 

+ + + + + T + + 

+ + 

0 

.000 

. 600E+01 

■r 


+ 

j 

.0 00 

. 800E+01 



+ 

r\ 

.000 

. 100E+02 

f 


+ 

129 1 

.000 

. 120E+02 

* 

A-*************************************** 

*+***++++ 

0 

.000 

. 140E + 02 

+ 


C 

0 

. 000 

. 160E* 02 

+ 


c 

0 

.000 

. 180E+02 

+ 


c 

0 

.000 

. 200E+02 

-t- 


c 

0 

.000 

. 220E+02 

+■ 


c 

0 

.000 

. 240E+02 

■f 


c 

0 

.000 

. 260E+02 



c 

0 

.000 

INF 

+■ 


c 

— 



+ 

+ + + + + + + + 

+ + 

139 



0 

20 40 60 80 

100 


**HISTOGRAM NUMBER 2** 
MEAN TURN TIME I 


OBS 

FREQ 

RE LA 
FREQ 

UPPER 
CELL LIM 

0 

20 40 60 80 

100 

0 

.000 

. 100E+02 

r 

+- 

+ + + + + + + + 

+ + 
+ 

0 

.000 

. 120E+02 

+ 



0 

.000 

. 140E + 02 

f 


+ 

139 1 

.000 

. 160E+02 

+ * 

* + * + *** + + + + ** + + + * + + + *** + + + * + + * + + + ±*4 r * * + 

•k’k + 'k'ie-k-it'k'k-k 

0 

.000 

. 1 80E + 02 

+ 


c 

0 

.000 

. 200E + 02 

+ 


c 

0 

.000 

. 220E+02 

+ 


c 

0 

.000 

.240E+02 

+ 


c 

0 

.000 

.260E4-02 

+ 


c 

0 

.000 

. 280E + 02 

+ 


c 

0 

.000 

. 300E+02 

+ 


c 

0 

.000 

INF 

+ 


c 

139 



+ 

0 

+ + + + -!- + + + 
20 40 60 80 

+ + 
100 
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Appendix C 


Output with minimum number of crews available for each system, 4 vehicles, and 1 crew 
assigned to scheduled maintenance for each system. The output report has been edited 


A M 


II SUMMARY REPORT 


SIMULATION PROJECT NAS AS IM 3Y DONOHUE 

DATE 3/29/1994 RUN NUMBER 1 OF 5 

CURRENT TIME . 1040E+C5 

STATISTICAL ARRAYS CLEARED AT TIME . 0000E+00 


♦♦STATISTICS FOR VARIABLES BASED ON OBSERVATION** 

MEAN STANDARD COEFF. OF MINIMUM MAXIMUM 

VALUE DEVIATION VARIATION VALUE VALUE 

MEAN MAI NT TIME .153E+02 .238E+01 . 156E+00 .I23E+02 .264E+02 

MEAN TURN TIME .198E + 02 .238E+01 .120E+Q0 .168E+02 .309E-I-02 


NO. OF 
OBS 
138 
138 


* * FILE STATISTICS** 



FILE 



AVERAGE 

STANDARD 

MAXIMUM 

CURRENT 

AVERAGE 


NUMBER 

LABEL/TYPE 

LENGTH 

DEVIATION 

LENGTH 

LENGTH 

WAIT TIME 


28 

Q1 

QUEUE 

.000 

. 000 

1 

0 

.000 


29 

Q2 

QUEUE 

1 . 658 

. 605 

3 

1 

120.547 


30 

Q3 

QUEUE 

. 847 

. 502 

3 

1 

63.394 


31 

Q4 

QUEUE 

.897 

.487 

3 

1 

67.130 


32 

Q5 

QUEUE 

.090 

M 

OO 

KO 

2 

1 

6.730 


33 

Q6 

QUEUE 

.266 

.466 

2 

1 

19.877 


34 

0.1 

QUEUE 

.293 

.473 

2 

0 

22.112 

53 

35 


CALENDAR 

13.594 

9.577 

53 

8 

2 . 058 


** REGULAR ACTIVITY S 

TATI ST ICS* * 



ACTIVITY 

AVERAGE 

STANDARD 

MAXIMUM 

CURRENT 

INDEX/LABEL 

UTILIZATION 

DEVIATION 

UTIL 

UTIL 

28 SUCCESSFUL M 

.3231 

.4677 

1 

0 

29 CRIT FAIL GO 

.0000 

.0000 

1 

0 


ENTITY 

COUNT 

140 

2 


* *RESOURCE STATISTICS** 



RESOURCE 

RESOURCE 

CURRENT 

AVERAGE 

STANDARD 

MAXIMUM 

CURRENT 


NUMBER 

LABEL 

CAPACITY 

UTIL 

DEVIATION 

UTIL 

UTIL 


1 

POWER 

1 

. 42 

.494 

1 

0 


2 

STRUC 

1 

.32 

.468 

1 

0 


3 

TANKS 

2 

1.13 

.810 

2 

1 


4 

AVION 

1 

.00 

.060 

1 

0 


5 

THERM 

25 

5.90 

8.824 

25 

1 

i -' 

6 

AUX 

1 

.59 

.492 

1 

1 


7 

LIFE 

1 

.37 

.482 

1 

1 


8 

MECH 

1 

.32 

.466 

1 

1 


9 

PROP 

16 

1.83 

2.580 

16 

1 
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Appendix D 


Output with minimum number of crews available for each system, 4 vehicles, and 
optimum number of crews assigned to scheduled maintenance for each system. The 
output report has been edited. 


SLAM II 
SIMULATION PROJECT NASASIM 
DATE 8/29/1994 
CURRENT TIME . 1040E+05 
STATISTICAL ARRAYS CLEARED AT TIME 


SUMMARY 


R E P 0 R 
BY DONOHUE 
RUN NUMBER 


. QGOOE+OO 


1 OF 


♦♦STATISTICS FOR VARIABLES BASED ON OBSERVATION* * 

MEAN STANDARD COEFF. OF MINIMUM MAXIMUM 

VALUE DEVIATION VARIATION VALUE VALUE 

MEAN MAINT TIME . 1C6E+02 .133E+01 .126E+00 .748E+01 .183E+02 
MEAN TURN TIME I . 151E+02 . 133E+01 .882E-01 . 120E+02 .228E+02 


NO. OF 
OBS 
139 
139 


FILE 

NUMBER 

♦♦FILE STATISTICS** 
AVERAGE 

LABEL/TYPE LENGTH 

STANDARD 

DEVIATION 

28 

Q1 

QUEUE 

.000 

.000 

29 

Q2 

QUEUE 

1.779 

.756 

30 

Q3 

QUEUE 

.370 

.485 

31 

Q4 

QUEUE 

. 420 

.495 

32 

Q5 

QUEUE 

.356 

.479 

33 

Q6 

QUEUE 

. 008 

.090 

34 

Q7 

QUEUE 

. 376 

.489 

35 


CALENDAR 

11. 802 

3.942 


MAXIMUM 

LENGTH 

1 

3 

2 

2 

2 

1 

2 

25 


CURRENT AVERAGE 


LENGTH 

0 

3 

0 

0 

0 

0 

0 

13 


WAIT TIME 
.000 
126.697 
27.717 
31.432 
26.610 
.616 
28.151 
1.830 


ACTIVITY 


♦♦REGULAR ACTIVITY STATISTICS** 
AVERAGE STANDARD 


INDEX/LABEL 

UTILIZATION 

DEVIATION UTIL 

28 SUCCESSFUL M .3231 

29 CRIT FAIL GO .0000 

** RESOURCE STATISTICS** 
RESOURCE RESOURCE CURRENT AVERACE 

.4677 

.0000 

STANDARD 

NUMBER 

LABEL 

CAPACITY 

UTIL 

DEVIATION 

1 

POWER 

i 

.41 

.492 

2 

STRUC 

1 

.32 

.465 

3 

TANKS 

3 

1.13 

1.303 

4 

AVION 

1 

.00 

.056 

5 

THERM 

8 

5.90 

3.002 

6 

AUX 

1 

.32 

,467 

7 

LIFE 

1 

.37 

.483 

8 

MECH 

1 

.32 

.466 

9 

PROP 

5 

1.94 

2.255 


MAXIMUM CURRENT ENTITY 
UTIL COUNT 

1 0 140 

1 0 3 


MAXIMUM CURRENT 


UTIL 

1 

1 

3 

1 

8 

1 

1 

1 

5 


UTIL 

0 

0 

0 

0 

8 

1 

1 

1 

5 
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Appenxdix E 


Output with minimum number of crews available for each system, 3 vehicles, and 
optimum number ot crews assigned to scheduled maintenance for each system. 

SLAM II SUMMARY REPORT 
SIMULATION PROJECT NASASIM BY DONOHUE 

DATE 8/29/1994 RUN NUMBER 1 OF 7 

CURRENT TIME . 1040E+05 

STATISTICAL ARRAYS CLEARED AT TIME .OOOOE+OO 

'♦STATISTICS FOR VARIABLES BASED ON OBSERVATION** 

MEAN STANDARD COEFF. OF MINIMUM MAXIMUM NO. OF 

VALUE DEVIATION VARIATION VALUE VALUE OBS 

MEAN MAI NT TIME .429E+01 .500E+00 .117E+00 .311E+01 .570E+01 140 

MEAN TURN TIME I .879E-t-01 .500E+00 .569E-01 .761E+01 .102E+02 140 

* * FILE STATISTICS** 



FILE 


AVERAGE 

STANDARD 

MAXIMUM 

CURRENT 

AVERAGE 


NUMBER 

LABEL/TYPE 

LENGTH 

DEVIATION 

LENGTH 

LENGTH 

WAIT TIME 


I 

R1 AWAIT 

. 034 

.240 

3 

0 

1.098 

y 

2 

SCH1 AWAIT 

.096 

.294 

1 

0 

7.106 


3 

OFF1 AWAIT 

.023 

.184 

3 

0 

1.721 

_ . 

4 

R2 AWAIT 

.019 

.224 

6 

0 

.533 

. ... 

5 

SCH2 AWAIT 

.054 

.225 

1 

0 

3.976 

LJ 

6 

OFF2 AWAIT 

.028 

.211 

3 

0 

3.287 


7 

R5 AWAIT 

.777 

2.400 

20 

0 

2 .185 


8 

SCH5 AWAIT 

. 194 

.395 

1 

0 

14.378 


9 

OFF5 AWAIT 

.049 

.308 

6 

0 

.969 


10 

R4 AWAIT 

.000 

.000 

0 

0 

.000 


11 

SCH4 AWAIT 

.000 

.000 

1 

0 

.000 

=■ 

12 

OFF4 AWAIT 

.000 

.000 

0 

0 

.000 

rm 

13 

R7 AWAIT 

.034 

.290 

6 

0 

.758 


14 

SCH7 AWAIT 

.047 

.212 

1 

0 

3.507 


15 

OFF7 AWAIT 

.027 

.219 

5 

0 

1.537 


16 

R8 AWAIT 

.023 

.278 

8 

0 

.426 


17 

SCH8 AWAIT 

.019 

. 136 

1 

0 

1.396 


18 

OFF8 AWAIT 

.140 

.499 

4 

0 

9.029 


19 

R9 AWAIT 

.145 

1.080 

17 

0 

.634 


20 

SCH9 AWAIT 

.067 

.249 

1 

0 

4 . 945 

n 

21 

OFF9 AWAIT 

.257 

.888 

9 

0 

3.452 


22 

R3 AWAIT 

.090 

.500 

6 

0 

1.165 


23 

SCH3 AWAIT 

.166 

.372 

1 

0 

12.313 

5 = 

24 

OFF3 AWAIT 

.027 

.185 

3 

0 

2.073 


25 

R6 AWAIT 

27.724 

15.007 

53 

53 

858.116 


26 

SCH6 AWAIT 

.087 

.282 

1 

0 

6.488 


27 

OFF6 AWAIT 

.004 

.059 

1 

0 

.455 

Cr^S 

28 

Q1 QUEUE 

.000 

.000 

1 

0 

.000 


29 

Q2 QUEUE 

1.852 

. 476 

3 

3 

133.785 


30 

Q3 QUEUE 

. 151 

.358 

1 

0 

11.251 


31 

Q4 QUEUE 

.149 

.356 

l 

0 

11.077 

i- -i 

32 

Q5 QUEUE 

.102 

.303 

1 

0 

7.594 

• 

33 

Q6 QUEUE 

.055 

.227 

1 

0 

4.049 


34 

Q7 QUEUE 

.029 

.167 

1 

0 

2.141 

___ 

35 

CALENDAR 

10.708 

10.694 

51 

1 

1.635 
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* 'REGULAR ACTIVITY STATISTICS** 




m 

ACTIVITY 

AVERAGE 

STANDARD 

MAXIMUM 

CURRENT 

ENTITY 


INDEX/ LABEL 

UTILIZATION 

DEVIATION 

UTIL 

UTIL 

COUNT 


- 

ON-VEH UNSCH 

.3342 

.8181 

3 

0 

855 

= — 

2 

ON-VEH SCH1 

.0557 

,2294 

i 

A 

140 

m 

3 

OFF-MAINT1 

.0068 

.0869 

2 

0 

142 


4 

ON-VEH UNSCH 

. 1080 

.4946 

3 

0 

380 


5 

ON-VEH SCH2 

.0661 

.2484 

1 

0 

140 


6 

OFF-MAINT2 

.0023 

.0503 

3 

0 

88 

V 

T 

ON-VEH UNSCH 

4.8106 

8.1994 

22 

0 

3697 


8 

ON-VEH SCH5 

.0942 

.2920 

1 

0 

140 

SS 

9 

OFF-MAINT5 

.0000 

.0000 

1 

0 

525 


10 

ON-VEH UNSCH 

.0000 

.0000 

0 

0 

0 


11 

ON-VEH SCH4 

.0023 

.0475 

1 

0 

140 


12 

OFF-MAINT4 

.0000 

.0000 

0 

0 

0 

s 

13 

ON-VEH UNSCH 

. 1452 

.5855 

3 

0 

464 

m 

14 

ON-VEH SCH7 

. 1095 

.3123 

1 

0 

140 


15 

OFF-MAINT7 

.0057 

.0757 

2 

0 

182 


16 

NO SPARE 

.0016 

.0394 

1 

0 

19 



17 

ON-VEH SCH8 

. 1403 

.3473 

1 

0 

140 

■ 

18 

OFF-MAINT8 

.0036 

.0697 

2 

0 

161 


19 

ON-VEH UNSCH 

. 4021 

1.7978 

10 

0 

2376 


20 

ON-VEH SCH9 

.1394 

.3463 

\ 

0 

140 

1 

21 

OFF-MAINT9 

.3011 

.7414 

6 

0 

773 

22 

ON-VEH UNSCH 

.7724 

1.7607 

6 

0 

799 


23 

ON-VEH SCH3 

.0800 

.2713 

1 

0 

140 


24 

OFF-MAINT3 

.0000 

.0000 

1 

0 

136 

■ 

25 

ON-VEH UNSCH 

.2717 

.7555 

3 

0 

283 

26 

ON-VEH SCH6 

.0999 

.2999 

1 

0 

140 


27 

OFF-MAINT6 

.0000 

.0000 

1 

0 

81 


28 

SUCCESSFUL M 

. 3231 

.4677 

1 

0 

140 

jj 

29 

CRIT FAIL GO 

,0000 

.0000 

1 

0 

1 



* ‘RESOURCE STATISTICS** 


RESOURCE 

RESOURCE 

CURRENT 

AVERAGE STANDARD MAXIMUM CURRENT 

m 

NUMBER 

LABEL 

CAPACITY 

UTIL DEVIATION UTIL UTIL 


1 

POWER 

3 

.43 

.959 

3 0 


2 

STRUC 

3 

.32 

.888 

3 0 

— 

3 

TANKS 

6 

1.21 

2.173 

6 0 

i p 

4 

AVION 

1 

.00 

.048 

1 0 


5 

THERM 

22 

5.94 

8.934 

22 0 


6 

AUX 

3 

.48 

.998 

3 0 



7 

LIFE 

3 

.38 

.885 

3 0 

■ 

8 

MECH 

2 

.33 

.735 

2 0 


9 

PROP 

10 

2.00 

3.714 

10 0 


RESOURCE 

RESOURCE 

CURRENT 

AVERAGE 

MINIMUM 

MAXIMUM 

M 

NUMBER 

LABEL 

AVAILABLE 

AVAILABLE 

AVAILABLE AVAILABLE 


1 

POWER 

3 

2.5730 

0 

3 


2 

STRUC 

3 

2.6796 

0 

3 

— 

3 

TANKS 

6 

4.7877 

0 

6 


4 

AVION 

1 

.9977 

0 

1 


5 

THERM 

22 

16.0596 

0 

22 


6 

AUX 

3 

2.5205 

0 

3 


7 

LIFE 

3 

2.6213 

0 

3 


8 

MECH 

2 

1.6732 

0 

n 

£. 


9 

PROP 

10 

8.0034 

0 

10 
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** HISTOGRAM NUMBER 1 + * 
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c 


— 



* + + + f + 

+ 

+ 

+ 

+ 

+ 


140 



0 20 40 

60 


80 


100 


1 



^HISTOGRAM NUMBER 2** 










MEAN TURN TIME I 






in 

OBS 
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